Standard Operating Procedure: Project Plan Template (MPP)

This Standard Operating Procedure (SOP) defines the systematic process for creating, customizing, and maintaining a project plan using the Microsoft Project (.mpp) file format. By adhering to this template-driven approach, Project Managers ensure consistency in scheduling, resource allocation, and tracking, thereby minimizing risks associated with scope creep and missed milestones. This document is intended for use by project management teams to maintain architectural integrity across the project portfolio.

Phase 1: Template Setup and Initialization

• Open the standardized master template (.mpt or .mpp) from the designated Project Management Office (PMO) repository.
• Perform a 'Save As' immediately, utilizing the naming convention: YYYYMMDD_ProjectName_V01.mpp.
• Navigate to the Project Information tab to define the Project Start Date and current scheduling method (Start-to-Finish vs. Finish-to-Start).
• Define the Project Calendar (Standard, 24-Hour, or Night Shift) under the 'Change Working Time' menu.
• Configure project properties (File > Info > Project Information > Advanced Properties) to include author, subject, and manager details.

Phase 2: Work Breakdown Structure (WBS) Development

• Input high-level project phases as Summary Tasks.
• Break down phases into granular, actionable tasks, ensuring each task has a duration of no more than 10-15 working days.
• Assign Task IDs (WBS numbering) to ensure clear traceability throughout the project lifecycle.
• Define Milestones by setting task durations to '0 days'.
• Identify and insert dependencies (Predecessors) to establish the critical path.

Phase 3: Resource Management and Budgeting

• Navigate to the Resource Sheet view to populate the resource pool (Labor, Material, and Cost resources).
• Define standard rates, overtime rates, and cost accrual methods (Start, Prorated, or End) for each resource.
• Assign specific resources to individual tasks via the Task Usage or Gantt Chart views.
• Level resources to identify and resolve overallocations that could delay the critical path.
• Apply budget costs to summary tasks to align the schedule with the financial baseline.

Phase 4: Baselining and Finalization

• Review the Critical Path (Format > Bar Styles > Critical Tasks) to ensure all dependencies are logically linked.
• Verify that all tasks have assigned resources or fixed-cost markers.
• Establish the Project Baseline (Project > Set Baseline) to capture the snapshot of the planned schedule and budget.
• Upload the finalized .mpp file to the project management portal/SharePoint and notify stakeholders.

Pro Tips & Pitfalls

• Pro Tip: Avoid manually entering dates. Let Microsoft Project calculate finish dates based on dependencies; manual date constraints create 'hard' deadlines that break the schedule logic when changes occur.
• Pro Tip: Use the 'Notes' field in task properties to document the rationale behind specific estimates or vendor dependencies.
• Pitfall: Over-linking. Avoid 'circular references' and excessive linking to milestones, which can clutter the Gantt chart and make it difficult to identify the true critical path.
• Pitfall: Ignoring resource calendars. Always ensure that holidays and non-working times are reflected in the resource calendar; failing to do so will result in an unrealistic delivery schedule.

Frequently Asked Questions (FAQ)

Q: How do I handle tasks that require multiple resources with different skill levels? A: Use the 'Resource Sheet' to define these as separate resources with different standard rates, then assign both to the task. Ensure the task type is set to 'Fixed Work' so the duration adjusts appropriately as effort is logged.

Q: Why should I avoid the 'As Soon As Possible' (ASAP) constraint? A: You shouldn't—in fact, ASAP is the preferred default. You should avoid 'Must Start On' or 'Finish No Later Than' constraints, as these override the scheduling engine and prevent the software from dynamically adjusting the timeline when predecessors slip.

Q: How often should I re-baseline the project? A: Generally, you should only re-baseline if the project scope has undergone a formal Change Request (CR) process. Baselining mid-project without a formal approval process obscures your actual performance against the original project commitment.