1. Assign resources only to regular project tasks
Meaning: resources (people) must be assigned to regular tasks rather than summary tasks, calendar tasks, or milestones. This ensures correct calculations of Work, Duration, and Cost.
MS Project practice: summary tasks aggregate data “from below,” so assigning resources directly to them distorts resource load and project metrics.
Example:
Simplistic: assign an engineer to the summary task “Installation.”
Correct: assign the engineer to “Cable‑tray installation,” “Cable laying,” “Cabinet connection.”
2. It is recommended to assign only one resource to each task
Meaning: one execution owner reduces managerial uncertainty — who reports progress, who updates % complete, and who is responsible for deadlines.
When it can be different: if the work can truly be performed in parallel (e.g., two installers working in different zones), it is better to split the task into two rather than mix two people in one activity.
Example:
Problematic: “Room finishing (2 resources)” — one reports 80%, the other 20%, resulting in incorrect totals.
Clear: “Finishing — Block A (Resource 1)” and “Finishing — Block B (Resource 2).”
3. Assign resources at 100% workload (by default)
Meaning: the basic norm is full availability for the task, which simplifies calculations. Exceptions (50%, 25%) should be intentional — for example, when a person works in parallel on other tasks or their role normally assumes part‑time involvement (e.g., an architect‑consultant at 25%).
MS Project practice: when the assignment is <100%, the duration will increase for the same amount of work (Work). This affects the critical path. You must understand task types (Fixed Units/Work/Duration) and the “Effort‑Driven” rule.
Example:
Baseline: analyst assigned to “Requirements gathering” = 100%.
Intentional exception: expert assigned to “Reviewing” = 25%, duration increases proportionally.
4. Only one responsible person can be assigned to a task or summary task
Meaning: besides performers, there must be a single Responsible/Owner to maintain clarity about who makes decisions, removes blockers, and approves changes.
Practice: even if multiple resources are assigned to a task, the “Responsible” role remains unique.
Example:
Three engineers work on “Commissioning,” but only one is responsible — the lead site engineer.
5. A responsible person can be assigned to both tasks and summary tasks
Meaning: at the operational level, the responsible person oversees a specific task; at the WBS (summary task) level, the responsible person acts as the curator for an entire work package.
Practice: this establishes a clear management hierarchy from micro‑tasks to large work packages.
Example:
Task “Interface testing” — Responsible: “QA Lead.”
Summary task “Communication System” — Responsible: “Head of Communications Department.”
6. It is recommended to store the responsible person in a custom Text field
Meaning: keeping the “Responsible” separately from resource assignments simplifies reporting, filtering, analytics, and exporting. A custom field (Text1/Text2 renamed to “Responsible”) prevents confusion between the person performing the work and the person responsible for the result.
MS Project practice:
- Rename the field Text1 → Responsible.
- Enter the full name/role of the responsible person (not necessarily the same as the assigned resource).
- Build filters/groupings “by Responsible” and generate reports with a single click.
Example:
Task has a resource “Electrical engineer (Ivanov)” but the Responsible field shows “Petrov A.A. (Department Head).” Petrov oversees the work; Ivanov performs it.
