Evaluate project margin software with a controlled sample project, not a feature checklist alone. Verify calculation transparency, pricing-scenario comparison, baseline handoff, actual-data entry, permissions, rollups, exports, audit evidence, accessibility, and documented limitations. Recalculate outputs independently and test missing data and scope changes. No product can improve margin without a sound cost policy, accurate inputs, and accountable decisions.
Terms used in this guide. fee: the amount charged to the client; cost: the expense included in the stated project model; margin: revenue left after the included costs; margin percentage = that amount / revenue × 100; baseline: the approved original plan kept for comparison.
In plain words
Evaluating project margin software means testing it on a real, small project instead of comparing feature lists. Enter the same project, check that the results match your own calculation, and see who can see what. If it cannot reproduce a number you already trust, it will not help you with the ones you do not.
Who this helps: Finance leaders, project management office staff and firm owners choosing a tool.
Questions this guide answers:
- How do you choose project margin software?
- What should you test in a margin tracking tool?
- How is margin software different from a spreadsheet?
Margin words: gross, contribution, managed margin, budget, forecast and the roles named here are defined once in the margin vocabulary.
What is project margin management software, in plain words?
Most firms start with a spreadsheet that prices a project and tracks it. Project margin management software does the same job with more structure and fewer hand-made copies.
- It prices a project from the team you plan to staff (roles, hours, rates).
- It keeps the plan you quoted on as a baseline, so it cannot quietly change.
- It compares actual hours and costs with the plan and shows the margin each week.
It does not replace judgment, a finance system or the people who set the cost policy. Evaluate it like any tool: decide what you need it to do, test it on a project whose answer you already know, and score what you find.
Start with the decision and accounting boundary
First decide what the system must help your team do. Common project-level decisions include pricing a fixed-fee proposal, selecting a role mix, comparing plan with actual hours, monitoring cost-budget consumption, reviewing service-order margin, or aggregating client and department results. These are different from statutory revenue recognition, workforce-capacity scheduling, or enterprise operating-margin reporting.
Write down the calculation policy before viewing software. At minimum, define:
- the approved revenue basis;
- commission treatment;
- labor cost-rate source;
- non-labor categories;
- shared-cost allocation;
- reporting currency;
- change-order rule;
- which margin layers users may see.
The UK Infrastructure and Projects Authority's guidance backs the same discipline for major-project cost estimates, and the reasoning transfers directly: a documented, evidenced policy is what turns a product demonstration into a reproducible test.
Build a controlled sample project
Create a small test that your team can calculate independently. The figures below are illustrative, not an industry benchmark. Use one fixed-fee project, two roles, a commission, one non-labor cost, a mid-delivery actual-hours update, and an approved change request.
| Test input | Illustrative value | Evidence to request |
|---|---|---|
| Approved project fee | USD 100,000 | Where the denominator appears and who may edit it. |
| Commission | USD 5,000 | Whether it reduces the delivery budget or enters another cost layer. |
| Senior role | 300 hours at USD 100 cost/hour | Rate source, effective date, and calculation trace. |
| Junior role | 300 hours at USD 50 cost/hour | Role, skill, location, and scenario behavior. |
| Infrastructure | USD 5,000 | Planned and actual treatment. |
| Actual-hours change | Senior +40; Junior -20 | Current recalculation and visible variance. |
| Scope change | USD 20,000 approved change request | Added value kept separate from the original baseline, with correct totals. |
Before the demonstration, calculate the expected planned labor cost: USD 30,000 plus USD 15,000, or USD 45,000. Calculate the other expected results too. With the USD 100,000 fee, USD 5,000 commission and USD 5,000 infrastructure, the planned margin is 100,000 − 45,000 − 5,000 − 5,000 = USD 45,000, or 45%. The actual-hours change (senior +40 at USD 100, junior −20 at USD 50) adds 4,000 − 1,000 = USD 3,000 of cost on the work recorded so far. Decide how the product recognizes revenue and estimates the remaining work before you call any result “actual margin”. Ask the vendor to show every transformation from inputs to gross-margin dollars and percentage. Then enter the same actual-hours change, verify the applicable rates, and recalculate independently. Missing rate, zero fee, and duplicate-scope tests are as important as the happy path.
Use a weighted evidence scorecard
Weighting prevents a polished secondary feature from compensating for an opaque core calculation. Adapt the weights to your risk and workflow; the example below totals 100 and is deliberately not a vendor ranking.
| Criterion | Example weight | Acceptable evidence |
|---|---|---|
| Calculation transparency | 20 | Reconciled input, formula, cost-layer, rounding, and exception results. |
| Pricing and baseline workflow | 15 | Scenario comparison and a controlled selected-plan handoff. |
| Actual-data and variance workflow | 15 | Dated actual entry, planned-versus-actual view, and traceable correction. |
| Permissions and sensitive data | 15 | Role tests for rates, dollars, percentages, edits, and exports. |
| Project and organizational rollups | 10 | Ratio-of-sums result with documented inclusion rules. |
| Audit and export evidence | 10 | Identifiable changes, dates, actors, and usable reconciliation output. |
| Usability and accessibility | 10 | Keyboard, focus, labels, errors, responsive layout, and representative user testing. |
| Implementation and limitations | 5 | Named owners, input process, support model, and written exclusions. |
Weighted score = sum of (criterion weight x evidence rating) / maximum rating
Define the rating scale before scoring. For example, zero can mean no evidence, one can mean a verbal claim, and higher ratings can require a successful test plus documentation. Record critical failures separately; a total score should not hide an unacceptable permission leak or irreconcilable calculation.
Worked example: scoring one vendor on a 0-3 scale
Assume a 0-3 rating scale (0 = no evidence, 1 = verbal claim, 2 = partial evidence, 3 = successful test plus documentation) and apply it to the eight weighted criteria above.
| Criterion | Weight | Rating (0-3) | Weight × rating |
|---|---|---|---|
| Calculation transparency | 20 | 3 | 60 |
| Pricing and baseline workflow | 15 | 2 | 30 |
| Actual-data and variance workflow | 15 | 3 | 45 |
| Permissions and sensitive data | 15 | 2 | 30 |
| Project and organizational rollups | 10 | 3 | 30 |
| Audit and export evidence | 10 | 2 | 20 |
| Usability and accessibility | 10 | 2 | 20 |
| Implementation and limitations | 5 | 3 | 15 |
| Total | 100 | – | 250 |
Weighted score = 250 ÷ 3 = 83.3 out of 100
This vendor scores well on calculation transparency and the actual-data workflow but only partial evidence on permissions and usability. An 83.3 total is not a purchase decision by itself: if the permissions walkthrough in the next section reveals a client-facing role can see internal pay rates, that critical failure should block the decision regardless of the score above it.
Test controls, audit evidence, and accessibility
Financial inputs deserve least-privilege access and a clear record of material changes. NIST describes access control as a core protection for systems containing financial and privacy information, while its security guidance covers defining audit events, audit-record content, review, and protection. These sources do not certify a vendor; they provide defensible questions for the evaluation.
- Can a presales user compare percentages without seeing sensitive cost rates?
- Can only authorized roles edit rate cards, actuals, and allocation rules?
- Can reviewers identify what changed, when, and by whom?
- Can exports be reconciled to screen totals and filtered populations?
- What happens when an authorized rate changes during a project's life?
Accessibility also belongs in the test plan. WCAG 2.2 is a W3C Recommendation with testable success criteria. Evaluate keyboard operation, visible focus, form labels, error identification, contrast, zoom, and responsive reading order in the actual workflows your users need. Do not treat a vendor statement as proof of conformance.
Where Managed Margin currently fits
Managed Margin connects project pricing with delivery-margin tracking for consulting and professional-services teams. The current product supports:
- resource profiles and planning rates by designation, seniority, specialization and location, with spreadsheet import;
- projects with one or more service orders, priced as fixed price or time and materials;
- pricing strategies on a weekly or monthly loading grid, compared side by side;
- cost rules and three margin layers: gross delivery margin, contribution margin and margin after all costs;
- finalizing one strategy as the approved pricing baseline, with planning-rate snapshots;
- handover by purchase order, signed agreement or approved exception;
- seats, named allocations, weekly timesheets, expenses and change requests in delivery;
- baseline, actual-to-date and forecast-at-completion margin per service order, project and business unit;
- role permissions that separate planning figures, project financials and protected employee cost;
- a BambooHR people-and-pay sync and API keys scoped by area.
Timesheets are entered by project managers for their team rather than by each person, and are not imported from other systems. There is no invoicing, cash or receivables tracking, and no net or operating margin. The forecast is a calculation from recorded actuals, remaining allocations and expected costs; it is only as good as those inputs.
Final evaluation checklist
- Write one primary workflow and explicit calculation boundary.
- Use identical controlled data for every shortlisted product.
- Recalculate the expected result outside the system.
- Test scenario comparison and selected-baseline handoff.
- Enter actuals, corrections, missing rates, and a scope change.
- For combined portfolio margin, sum the included margin amounts and divide by the matching revenue total. A simple average answers a different question: the average project percentage. It may be higher or lower than the combined margin.
- Test each representative role, including exports and direct URLs.
- Inspect audit evidence and data-retention behavior.
- Run keyboard, zoom, error, and responsive-layout checks.
- Document integrations, forecasts, margin layers, and other exclusions in the decision record.
- Name the internal owners for rate policy, actual entry, review cadence, and exceptions.
Use the professional-services project margin guide to define the workflow, the calculation guide to build your expected result, the weighted rollup guide to test aggregation, and Managed Margin pricing when assessing total fit.
At the office: Karen runs a small pilot
An illustrative story with invented figures, to show how the idea works in a real office.
Karen, an operations manager, has two tools to compare. She takes a finished project whose margin she knows: fee USD 60,000, cost USD 40,000, margin 33.3%. She enters it into each tool.
Tool A gives 33.3% and shows exactly how. Tool B gives 31% and cannot show why. She then checks permissions: in Tool A, a sales user cannot see staff pay rates; in Tool B, they can.
The choice is easy. Karen also writes down a limit she found in Tool A so nobody is surprised later.
Who evaluates margin software, and what do they check?
| Step | Owner | Checkpoint |
|---|---|---|
| Define the decision | Operations manager and finance | One primary workflow and the accounting boundary are written down |
| Build a sample project | Finance analyst | A small project whose margin you can calculate yourself |
| Test each vendor with the same data | Operations manager | Result matches your own calculation |
| Test controls | IT and finance | Access, audit trail and exports behave as needed |
| Score and decide | Leadership | Weighted scorecard with evidence, not a feature count |
Frequently asked questions
What should a sample project include?
One fixed-fee project with two or three roles, a commission, one non-labor cost and a scope change, plus a set of actual hours. Work out the expected margin yourself first, then check that each product gives the same answer and shows how it got there.
How do I score vendors fairly?
Weight criteria by decision importance, score them from observed results and have two people score independently.
Where does Managed Margin fit?
The guide states where Managed Margin currently fits and what it does not do; read that section before comparing.
What is project margin management software?
Software that prices a services project from roles, hours and rates, keeps the approved plan as a baseline, and compares actual hours and costs with it to show margin during delivery. It supports a cost policy and a review process; it does not replace them.
- Replace a Project Margin Spreadsheet: When and How
- How to Audit a Project Margin Spreadsheet
- What Is Managed Margin? Meaning, Formula and Software
- Resource Loading Scenarios: Compare Team Options for a Bid
- Project Baseline Handoff: From Sales to Delivery
- How to Share Project Margin With Sales Without Showing Salaries
- How to Structure a Project Margin Spreadsheet
Continue the sequence: guides to read next
- How to Structure a Project Margin Spreadsheet: how to structure a project margin spreadsheet
- How to Audit a Project Margin Spreadsheet: what your current sheet gets right
- Replace a Project Margin Spreadsheet: When and How: the decision before evaluation
- What Is Managed Margin? Meaning, Formula and Software: what Managed Margin does and does not do
- Resource Loading Scenarios: Compare Team Options for a Bid: a scenario test to put to any vendor
- Project Baseline Handoff: From Sales to Delivery: the sales-to-delivery handoff to test
- How to Share Project Margin With Sales Without Showing Salaries: a permissions case to test
Sources and methodology
- UK Infrastructure and Projects Authority, Cost Estimating Guidance, published 17 March 2021. Used for methodology, assumptions, exclusions, evidence, ownership, and consistent baseline principles.
- U.S. National Institute of Standards and Technology, Assessment of Access Control Systems. Used to frame authorization and sensitive-data evaluation questions.
- U.S. National Institute of Standards and Technology, NIST SP 800-171 Revision 3. Used for audit-event, audit-record content, review, and protection questions; not as a product-compliance claim.
- World Wide Web Consortium, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation updated 12 December 2024. Used for accessibility-test categories.
- Managed Margin capabilities and limitations were reviewed against the current Managed Margin application on 26 September 2026. Test figures, weights, and ratings are illustrative and should be adapted to the buyer's policy and risk.