Picking a PMIS for Your Megaproject

101: define the job before choosing the system

A project management information system, or PMIS, can cover very different territory. For this guide, it means the connected tools and information processes used to manage delivery: for example cost, change, documents, workflows and reporting. Your scheduling, finance, engineering and asset systems may remain separate. Write the boundary you need instead of assuming that every supplier means the same thing by PMIS.

Start with the work that needs to improve. Which decisions arrive late? Where do people repeat entry, lose approvals or reconstruct the previous reporting position? Choose a small set of outcomes that the delivery team can recognise and measure. A new system may help, but a missing process owner will still need a decision.

Agree how the project will work across organisations

Bring delivery leaders, actual users, information owners, IT and security, commercial colleagues and the eventual operator into the selection. Map which organisation supplies, reviews, approves and keeps each record. Decide which existing systems will remain authoritative for which purposes. An owner, joint venture and contractor may each need an interface without using the same application for every task.

Describe the arrangements the purchase must respect: delivery phases, contract packages, delegated approvals, external collaborators and handover responsibilities. Name one accountable owner for the PMIS service and an agreed route for resolving conflicting requirements. A product supplier can explain options; the project still has to choose its operating model.

Write requirements as work that can be demonstrated

Turn a feature request into a scenario with an actor, a starting record, a decision and an expected result. Distinguish essential conditions from useful improvements, and record who owns each requirement. Keep a reason for every essential condition so an old habit does not quietly become an expensive customisation.

Scroll sideways or use the arrow keys to see all columns.

Use representative, permitted examples. Include difficult paths such as a rejected submission, missing approver or returned document, as well as the successful route.

Resolve the data wars in the requirements

Separate the questions of who owns information, who hosts it, who may use it and which version has authority for a particular purpose. Connecting two systems does not by itself settle those rights. Ask the appropriate commercial and information owners to turn the agreed position into requirements, permissions and contract terms.

• Specify who can create, review, approve, correct, export and administer each important class of record.
• Test the experience and cost for occasional users, contractors and the eventual owner or operator, not only the core project team.
• State how current operational information differs from issued reporting periods, approved changes and superseded documents.
• Identify sensitive information and the applicable access, location, retention and preservation requirements before configuring the system.

Document the supplier's permitted uses of project information, including any AI features, and have the responsible specialists assess those terms. Product ownership claims and security badges are starting points for questions, not evidence that your particular arrangement meets its requirements.

Test the connections that the project will depend on

An integration claim needs a concrete flow to test. Pick a real boundary, such as a package forecast moving from project controls to finance or a drawing revision reaching a contractor. Agree identifiers, units, dates, update direction and conflict handling before demonstrating the transfer. Ask who will maintain the connection after either product changes.

• Show an initial load, a changed record, a duplicate submission, a missing mapping and a failed transfer followed by recovery.
• Check that corrections and deletions are handled deliberately, rather than creating a second unexplained record.
• Identify API or connector access, commercial limits, supported versions, monitoring and ownership of failures.
• Have security and IT colleagues assess identity management, role permissions, audit evidence, recovery and the actual deployment arrangement.

Keep the test results and unresolved limitations. A connector in a brochure is not the same as an approved, monitored interface for your project. Export formats also need to preserve enough meaning and relationships for the receiving system.

Make the demonstration do your work

Give shortlisted suppliers the same representative scenarios and the conditions under which you will assess them. Ask the people who will enter, review and approve information to try those tasks. Record what works today, what needs configuration, what requires custom development and what exists only on a roadmap.

• Ask for a complete workflow rather than a sequence of disconnected screens.
• Observe the effort at the point of entry, including mobile use, accessibility needs and limited connectivity where relevant.
• Set acceptance criteria before a proof of concept. Record whether each criterion was met and what evidence supports the result.
• Agree a bounded test environment, permitted data, responsibilities, cost and disposal arrangements before supplying project information.

A polished demonstration can still leave a critical question unanswered. Use a proportionate proof of concept to investigate those questions before commitment, with a clear decision at its end. Do not describe a supplier promise as a completed test.

Compare the whole commitment

Build a comparison around the service you will actually operate. Ask each supplier to price the same user groups, data volumes, interfaces, environments and delivery assumptions. Separate the software subscription from the work needed to implement and sustain it.

• Include configuration, migration, data cleanup, integration, testing and any custom development.
• Include internal subject-matter experts, administrators, training time, contractor onboarding and support.
• Check recurring charges for users, external collaborators, storage, interfaces, analytics and required environments.
• Examine upgrade effort, ongoing changes, archive access and the time and cost of transition at the end.

Agree the evaluation method with procurement before bids arrive, using the applicable procurement process. Compare demonstrated fit, unresolved risk and total commitment alongside price. Essential access, security or records requirements need an explicit decision; a strong overall score does not make an unresolved essential condition disappear. Capture material delivery commitments in the agreement with appropriate commercial review.

Buy the implementation capacity as well as the software

Treat rollout as a project with an owner, realistic capacity and acceptance points. Decide who will clean and map the data, configure workflows, maintain interfaces, approve permissions, train users and operate support. Check which tasks the supplier will perform and which your team must provide.

Begin with a representative, manageable scope that tests the difficult assumptions. Have users practise their actual submissions, corrections and approvals. Track the effort, errors and workarounds they encounter, then decide what must change before expansion. Training attendance alone does not show that a team can complete the workflow.

• Reconcile migrated records and preserve the agreed evidence from the previous system.
• Set cutover and rollback criteria, including what happens to work entered during the transition.
• Explain where the authoritative record lives during any parallel operation and how duplicates will be resolved.
• Keep support and process ownership available through the first reporting cycles and contractor onboarding.

Know how the project will leave the system

Request an exit demonstration before signing. Export a representative package, then ask the intended recipient to locate a record, open its attachments and understand its revision and approval history. Compare the result with the retention and handover requirements you agreed. A collection of files can be complete in volume and still be unusable without identifiers and context.

Agree transition assistance, formats, timing, responsibilities and charges while there is still a choice. Establish what access survives subscription end, how remaining records are retained or disposed of, and how any continuing preservation obligation will be handled. Keep the exit plan current as interfaces, suppliers and project phases change.

Leave the selection with an operating plan

A useful selection record explains why the chosen approach fits the work, what remains uncertain and who will resolve it. Keep the alternatives, evaluation evidence, exceptions and decision together so the next team can understand the choice when conditions change.

• The intended outcomes, system boundaries and responsible service owner are agreed.
• Users and information owners have tested the workflows that matter, including failures and corrections.
• Integration, access, data rights and reporting-history requirements have evidence or an explicit unresolved decision.
• The cost comparison includes internal effort, implementation, operation and exit.
• The rollout has people, time, acceptance points and a route to support users.
• The team can retrieve and hand over a meaningful project record when an organisation or supplier leaves.

After launch, compare the actual workflow with the outcomes you set at the start. Are approvals reaching the right people, are records reliable, and can the team produce and explain the required information? Use that evidence to improve the service as the project develops.