Microsoft Project for construction teams

Build a site calendar before trusting the completion date

Start a construction programme by setting the project start date and working calendar, then add holidays, planned shutdowns and non-working weekends. Create separate resource calendars where crews or plant follow different shifts. In Project, working time determines how durations translate into dates: a five-day activity is not necessarily five consecutive calendar days. Check the hours-per-day setting as well; changing that conversion setting does not itself change the working hours in the calendar.

Use automatically scheduled tasks for activities whose dates should respond to dependencies and resource availability. Link the actual construction sequence, favouring finish-to-start relationships where appropriate, and use other dependency types only when the overlap is defensible. Avoid fixing every activity with a Must Start On constraint, because this restricts useful recalculation. Resource levelling can delay or split eligible tasks to resolve overallocations, but it cannot decide whether a revised sequence is physically safe or contractually acceptable.

• Enter site shutdowns as calendar exceptions rather than artificial activities.
• Use deadlines to flag target-date breaches without fixing the task date.
• Check whether resource calendars explain unexpected gaps in the programme.
• Review levelling settings before allowing tasks to split.
• Inspect the critical path again after calendar or resource changes.

Run a disciplined weekly update without overwriting the baseline

Save a baseline after the agreed programme has been checked, then retain a dated copy of the issued file. A baseline stores reference values for later comparison; it is not a locked or independently approved record. Project supports an initial baseline plus ten additional numbered baselines. Use those deliberately for authorised revisions rather than replacing the original every week, and document which baseline represents the contract programme, an approved change or an internal recovery scenario.

For each reporting cycle, set a status date and collect actual starts, actual finishes and remaining durations from the site team. Do not treat task percentage complete as a measurement of installed quantities: Project's % Complete field is duration-based, while % Work Complete concerns work. Update the remaining forecast, then use the rescheduling options to move unfinished work after the status date where appropriate. Review out-of-sequence progress and milestone variance before issuing a new report.

• Agree one reporting cut-off date across subcontractors.
• Record physical quantities separately when duration progress would mislead.
• Investigate actual dates that fall after the reporting cut-off.
• Use Tracking Gantt to compare the current programme with a baseline.
• Keep a revision log explaining approved changes and forecast movements.

Validate Primavera handovers instead of assuming XER compatibility

Microsoft Project desktop does not natively open Primavera P6 XER files. If the main contractor issues XER, agree an exchange route before choosing your workflow: request a compatible export or use a separately evaluated conversion tool. Microsoft Project XML and Primavera XML are not interchangeable merely because both use the .xml extension. Test a representative programme first, particularly where the contract relies on precise calendar behaviour, activity codes, relationship lags or resource assignments.

Treat every converted programme as a new dataset requiring reconciliation, not as an exact copy of the source schedule. Compare task counts, milestone dates, working calendars, durations and predecessor relationships against a reference report from P6. Inspect constraints and any activities whose dates moved during conversion. Preserve the original file and the conversion settings so discrepancies can be traced. For recurring exchanges, agree stable identifiers and field mappings rather than attempting to match activities by their names alone.

• Ask the sender for the source schedule's data date and calendar definitions.
• Confirm which application and format will govern contractual submissions.
• Check elapsed durations and lag units explicitly.
• Verify WBS structure and custom-field mappings.
• Issue a discrepancy list before accepting the converted programme.

Separate desktop licensing from shared access and server services

Choose the edition by the required functions, then verify the licence channel and deployment rights. A standalone Project desktop licence is separate from an Office suite licence; owning Office does not grant Project use rights. Microsoft's retail desktop terms generally license installation and use on one licensed device, with one person using it at a time. Volume licensing and subscription arrangements have their own terms, so do not assume that a product key alone proves entitlement or transfer rights.

Project Professional's server connectivity does not include a hosted service, server licence or every required access entitlement. Project Online and Project Server are distinct offerings, and Microsoft has announced Project Online retirement on 30 September 2026; that announcement does not retire the Project desktop application. Before purchasing for collaboration, identify the actual service, its lifecycle and compatible client versions. For Remote Desktop Services, shared virtual machines or contractor access, check the applicable Microsoft terms rather than extrapolating from a single-PC installation.

• Obtain documentation identifying the product, edition and licence channel.
• Check the applicable transfer rules before moving Project to another PC.
• Confirm server and user access licensing separately from desktop licensing.
• Plan a supported replacement before relying on Project Online.
• Use PDF reports for recipients who only need to read issued programmes.

Project 2024 desktop capabilities relevant to construction planning