Best Practices

This article describes proven practices for four critical decision points in project planning with Rillsoft Project: building a clean project structure, planning resource demand, preparing portfolio reviews, and saving baselines at the right time.

Build A Clean Project Structure

A clean project structure is the foundation for reliable scheduling, understandable capacity balancing, and meaningful variance analysis. Structural mistakes at the beginning create follow-up errors in every later planning phase.

Basic rule: structure before dates

Clarify the business structure before entering durations, dates, or resources. Detailed work does not improve a poorly structured plan.

Good project structure:

  • Each subproject represents a coherent unit, such as phase, trade, deliverable, site, or department.

  • Activity names describe a result or a completed piece of work.

  • The structure is readable for project managers, resource managers, and management.

  • Milestones mark real decision points, not every minor interim step.

Avoid common structure errors:

Error

Better approach

All activities on one level

Use subprojects for business sections.

Too many levels

Reduce levels and move excessive detail into subproject files.

Activity names such as “work on X”

Use result-oriented names such as “X approved”.

One activity for a six-month phase

Split phases into controllable activities.

Milestones for every activity

Use milestones for approvals, delivery dates, and phase transitions.

Plan Role Demand Before Employee Assignment

The most common resource planning error is assigning employees before qualification-based demand is understood. This creates overloads that become visible too late and capacity decisions without a reliable basis.

Principle:

  1. Activities first receive roles or professional qualifications, not names.

  2. Capacity balancing shows whether enough qualified capacity is available.

  3. Named employees are assigned only after capacity balancing.

This approach is especially useful when several projects compete for the same resource pool, when absences matter, or when the organisation needs to know whether projects are feasible before committing named people.

After employee assignment, check:

  • Does capacity balancing show shortfall or overload?

  • Does the employee’s qualification match the assigned role?

  • Are working times and non-working days maintained?

  • Is the assignment plausible in portfolio context?

Prepare Portfolio Reviews

A portfolio review prepares decisions, not reports. A report shows the current state. A review should help decision makers change priorities, resources, or dates when needed.

Before the review, update:

  • project status of all active projects

  • project priorities

  • baseline status and current progress

  • resource utilisation in the portfolio horizon

  • cross-project links and delays

Three core questions:

  1. Is the portfolio feasible?

  2. Which projects are at risk?

  3. What must be decided?

Portfolio chart for review preparation

Good review material contains the affected projects, the bottleneck qualification or resource, the timing, the available alternatives, and a recommended decision.

Save Baselines At The Right Time

The baseline is the reference for variance analysis. The timing of the baseline determines the quality of every later comparison.

Saved too early

The current plan is compared with an immature planning state. Variances are misleading.

Saved too late

The reference is missing when changes already happened. A later baseline may reflect the current situation instead of the approved plan.

Save the baseline when:

  • the schedule has been reviewed and approved

  • resource demand and capacity balancing are complete

  • important employee assignments are made

  • costs, effort, and milestones are binding

  • the project officially enters execution

Save baseline from the menu

Use multiple baselines deliberately:

  • Baseline 1: original approved plan.

  • Baseline 2: revised plan after an approved change.

  • Baseline 3: plan after scope extension.

Each new baseline should document why it was saved.