Project Online RFP Template: The Evaluation Criteria That Actually Matter

Here is a test. Pull up the Project Online RFP template your PMO built for the replacement evaluation. Find the section on dependency type support. Does it distinguish between FS, SS, FF, and SF dependencies with lag values, or does it just ask "does the tool support task dependencies?" Find the baseline migration section. Does it ask whether baselines are preserved as historical phantom-bar records or collapsed into static date copies? Find the data-import section. Does it require vendors to demonstrate fidelity on your own .mpp file, or does it let them use their sample project?

If the answer to most of those questions is "our RFP doesn't go that deep," you are about to buy a tool based on a checklist where every vendor checked every box.

This post is a ready-to-adapt Project Online RFP template organized around the five sections that separate real tools from brochure claims. Each section includes the actual questions to ask, how to score responses, and how to weight the results so that functional depth beats slick demos.

The short version Weight your RFP: functional (40%), data migration (20%), security (20%), AI (10%), commercial (10%). Require a live demo on your own .mpp file, not the vendor's sample data. Dependency type fidelity and baseline preservation are the two tests most tools fail quietly. Project Online retires September 30, 2026: your RFP needs to close before Q3 if you want a June–July cutover buffer. Use the Migration Cost Calculator to build the budget section before the RFP goes out.

Why Feature Checklists Fail (and What to Use Instead)

Every PM tool vendor will answer "yes" to a yes/no feature checklist. "Does the tool support dependencies?" Yes. "Does it support baselines?" Yes. "Does it import .mpp files?" Yes.

Those answers are technically true and operationally useless. A tool may support "dependencies" but only implement FS without lag, which silently corrupts roughly 30% of a typical Project Online schedule on import. It may support "baselines" but store them as flat date copies rather than as phantom-bar records you can view on the Gantt against the current schedule. It may "import .mpp" while losing enterprise custom field types, converting typed fields to plain text strings.

The fix is not a longer checklist. It is a different kind of question: one that requires the vendor to show evidence rather than check a box.

Microsoft's own Project Online service description defines the feature surface you are replacing. Your RFP needs to probe the delta between what Project Online provided and what the replacement actually delivers, not whether the replacement has any version of those capabilities at all.

For context on the most common reasons migrations go wrong after a vendor is selected, see Why Most Project Online Migrations Fail.

Before the template sections, set up the scoring framework. This is the table your evaluation committee scores each vendor against.

Category	Weight	Scoring method
Functional requirements	40%	0–5 scale per criterion, averaged
Data migration fidelity	20%	Pass/fail on live demo items, then 0–5
Security and deployment	20%	Certification evidence required
AI features	10%	0–5 per criterion, demo required
Commercial and pricing	10%	TCO model, scenarios required
Total	100%	Weighted score 0–5

The diagram below shows how those weights map visually across the five categories and what a strong versus weak response looks like for each.

Cap commercial/pricing at 10%. A vendor who wins on price but loses on dependency fidelity will cost far more in schedule re-entry than the license savings justify.

Section 1: Functional Requirements (Weight 40%)

This is the section where most feature checklists collapse into useless yes/no answers. Rewrite each question as a demonstration requirement.

1.1 Dependency type support

Ask the vendor to import a schedule that contains all four dependency types: Finish-to-Start (FS), Start-to-Start (SS), Finish-to-Finish (FF), and Start-to-Finish (SF), each with non-zero lag values. After import, verify:

• All four types are preserved (not coerced to FS)
• Lag values are intact, not zeroed or dropped
• The critical path recalculates correctly after a date change

1.2 Baseline preservation

Project Online stores baselines as historical records that display as phantom bars on the Gantt. Ask the vendor to demonstrate that baselines imported from your .mpp file appear as distinct timeline bars against the current schedule, not just stored as start/finish date metadata.

1.3 Enterprise custom field (ECF) type fidelity

Project Online ECFs include typed fields: cost, duration, flag, number, text, and date. Ask the vendor to show that after import, a cost ECF is still a cost field (not a text string), a duration ECF retains its units, and a flag ECF renders as a boolean rather than "True"/"False" text.

1.4 .mpp and MSPDI XML import fidelity

Require the vendor to import both formats: the binary .mpp format and the MSPDI XML format that Project Online's OData export produces. Evaluate the result against the source file using Migration Preview or your own side-by-side comparison.

Scoring rubric for Section 1:

Score	Meaning
5	All four dependency types with lag, baselines as phantom bars, typed ECFs, both import formats pass
4	Three of four items above; one minor gap that vendor can roadmap with committed date
3	Two items; notable gaps in lag or baseline fidelity
2	Only FS dependencies; baselines as flat date copies
1	Basic import with visual Gantt but no fidelity validation available
0	Cannot import .mpp or produce side-by-side validation

Section 2: Data Migration Fidelity (Weight 20%)

This section covers the migration process itself, separate from whether the tool supports the features. A tool can theoretically support baselines but run a migration service that collapses them during import. Treat these as distinct concerns.

2.1 The live demo requirement

This is non-negotiable: require each shortlisted vendor to run their live demo on one of your own .mpp files. Provide a file that is representative of your most complex active project: multiple dependency types, at least two saved baselines, resource assignments with custom fields, and calendar exceptions.

Vendors who decline or insist on using their own sample data are telling you something important.

2.2 Round-trip fidelity test

Export a project from Project Online in MSPDI XML format, import it into the vendor's tool, then export it from the vendor's tool back to .mpp or XML, and compare the two source files. Count the fields that changed. This is the only objective measure of import fidelity.

2.3 Historical archive migration

Ask how the vendor handles projects in read-only archived status. Project Online retirement means you will migrate both active projects and a potentially large archive of closed projects. Ask whether archive projects import differently, whether baselines are preserved, and what the per-project migration time estimate is.

See the Project Online Migration Checklist for a complete inventory of the source-side data you need to migrate, beyond just the .mpp files.

Section 3: Deployment and Security (Weight 20%)

PMOs at mid-size and enterprise organizations cannot accept a vendor who fails on security requirements. Treat this section as pass/fail for minimum requirements, then use the 0–5 scale for differentiated capabilities.

Minimum requirements (pass/fail):

• SOC 2 Type II: Require a current report (issued within the past 12 months). SOC 2 Type I is not equivalent; Type II covers operational controls over time, not just at a point-in-time audit.
• Data residency: Ask whether data is stored in a geography you can specify. For organizations with EU data residency requirements, this is a hard filter.
• SSO/SCIM: Require support for your identity provider via SAML 2.0 or OIDC, plus SCIM provisioning so that user offboarding is automatic rather than manual.

Differentiated questions (0–5 scale):

• Penetration test schedule and most recent report availability
• Data encryption at rest and in transit (AES-256, TLS 1.2+)
• Role-based access control at project and field level
• Audit logging: who changed what, when, with IP address

Deployment options: Ask whether dedicated-tenant or shared multi-tenant is available. For most PMOs SaaS shared-tenant is sufficient, but confirm with your infosec team before the RFP closes.

Section 4: AI Features (Weight 10%)

Weight AI at 10%, not higher. AI features are a tiebreaker after a vendor has passed functional and security requirements, not a selection criterion. A vendor with excellent schedule math and weak AI beats a vendor with impressive AI demos and broken dependency fidelity every time.

That said, evaluate four specific capabilities: (1) schedule risk detection that flags critical-path conflicts and float shortages proactively, not on demand; (2) resource leveling suggestions that respect dependency constraints; (3) natural language queries against live schedule data ("What happens to the portfolio if Task 14 slips two weeks?"); and (4) explainability, meaning the AI shows its reasoning, not just its output. Unexplained AI suggestions are ignored or blindly applied; both outcomes are bad.

Require a live demo of the AI features on your schedule, not a recorded video. For a look at how Onplana implements these capabilities, see our features overview.

Section 5: Commercial Terms and Pricing (Weight 10%)

Pricing is capped at 10% because an under-qualified tool at 20% less per user will cost far more in migration remediation and re-entry labor than the license savings justify. That said, commercial terms carry risk that needs explicit evaluation.

5.1 Pricing model

Ask for a full TCO model, not a per-user-per-month number. The TCO should include: per-user license cost at your user count, implementation/migration services fee, training, annual support, and any integration fees. Require low/mid/high scenarios.

Run those scenarios through the Migration Cost Calculator alongside your internal cost estimates so you are comparing apples to apples across vendors.

5.2 Migration services

Ask whether data migration is included, what the SLA is for fidelity issues discovered post-migration, and who owns remediation if ECF types are lost during import. Vendors who exclude migration or cap their fidelity SLA at "commercially reasonable efforts" are transferring significant risk to you.

5.3 Exit terms

Ask for your data in standard format (MSPDI XML or .mpp) on demand, at no fee, at any time during the contract. Vendor lock-in risk is real in the PMO software space; a vendor who cannot commit to clean data portability is a risk you carry for the life of the contract.

5.4 Contract length and price lock: Ask for a 2-year term with a price-lock clause. A 1-year term with uncapped renewal increases is common practice and worth pushing back on. For a deeper breakdown of migration budget line items, see Build a CFO-Proof Business Case for Your Project Online Migration.

The RFP Template Text

Copy the following sections into your RFP document and adapt the specifics to your organization. The numbered format is intentional: vendors should respond to each item individually, not with a single narrative response.

---

SECTION A: FUNCTIONAL REQUIREMENTS

Respond to each item with: (a) current availability (GA/Beta/Roadmap/Not planned), (b) brief description of implementation, and (c) link to documentation or demo.

1. Dependency type support

   • 1a. List all supported dependency types (FS, SS, FF, SF)
   • 1b. Confirm whether lag and lead values are preserved on .mpp import. Provide a demonstration on the buyer-provided sample file.
   • 1c. Describe how the tool recalculates the critical path after a dependency change.

2. Baseline management

   • 2a. Describe how baselines are stored. Are they accessible as historical Gantt overlays or only as date metadata?
   • 2b. How many baselines per project are supported?
   • 2c. On .mpp import, are existing baselines preserved as historical records or collapsed?

3. Enterprise custom field fidelity

   • 3a. List all supported ECF types (cost, duration, flag, number, text, date, etc.)
   • 3b. On import from Project Online, are typed ECFs preserved with their original type, or coerced to text?
   • 3c. Describe how lookup tables attached to ECFs are handled on import.

4. File format support

   • 4a. Confirm .mpp import support. Specify the most recent .mpp format version tested.
   • 4b. Confirm MSPDI XML import support.
   • 4c. Provide a round-trip fidelity report on the buyer-provided sample file.

SECTION B: DATA MIGRATION

1. Live demo requirement

   • 1a. Acknowledge that the evaluation demo will be conducted on a sample .mpp file provided by the buyer, not vendor sample data.
   • 1b. Describe your migration process from first export to validated production load.
   • 1c. What is your SLA for resolving fidelity defects discovered post-migration?

2. Archive migration

   • 2a. How are closed/archived projects handled? Are they migrated differently from active projects?
   • 2b. What is your estimated per-project migration time for a schedule of 200 tasks with 5 baselines?

3. Historical reporting data

   • 3a. How is Project Online OData reporting history migrated? What happens to Power BI reports that depend on it?

SECTION C: DEPLOYMENT AND SECURITY

1. Compliance

   • 1a. Provide current SOC 2 Type II report (issued within past 12 months).
   • 1b. Confirm GDPR compliance. Specify data residency regions available.
   • 1c. Provide most recent penetration test summary.

2. Identity and access

   • 2a. List supported SSO protocols (SAML 2.0, OIDC, etc.)
   • 2b. Confirm SCIM provisioning support and which identity providers are tested.
   • 2c. Describe role-based access control granularity (project-level, field-level, resource-level).

3. Data encryption and portability

   • 3a. Confirm AES-256 encryption at rest and TLS 1.2+ in transit.
   • 3b. Confirm that buyer data is exportable in MSPDI XML or .mpp format on demand at no fee.

SECTION D: AI FEATURES

1. Describe all AI capabilities currently in GA (not roadmap). For each: feature name, data inputs, output format, and how the AI explains its recommendation to the user.
2. Schedule risk: Does the AI identify critical-path risk proactively? Demonstrate on buyer-provided schedule.
3. Resource leveling: Does the AI suggest leveling options that respect dependency constraints?

SECTION E: COMMERCIAL TERMS

1. Provide a full 3-year TCO model at [your user count] named users: license, implementation, training, support, integration.
2. Confirm whether migration services are included or quoted separately.
3. Confirm price lock through end of initial contract term.
4. Confirm data portability: MSPDI XML or .mpp export on demand, at no fee, at any time.

---

Running the Evaluation

Once responses are in, score each vendor 0–5 per section, multiply by the section weight, and sum. The highest weighted score advances to the live demo round.

For the demo, send each finalist the same .mpp file: your most complex active schedule, not a simplified test file. Evaluate against the functional items in Section 1. A vendor who scores 5 on a real schedule has earned it. A vendor who scored 5 in writing but stumbles on the live demo has told you something important.

Reserve the right to disqualify any vendor who declines the live demo on your file. That refusal is informative.

Build your migration budget before the RFP goes out The Migration Cost Calculator models low-mid-high scenarios based on your user count, project count, and integration inventory, exactly what the pricing section of your RFP needs. No signup required. → Open the Migration Cost Calculator

Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.