Brainforge Knowledge

project-management-standards

3 min read

Project management standards

Purpose: PM doctrine for Brainforge delivery. It defines the discipline required to move from scope to execution without losing clarity, control, or trust.

This is the operational layer beneath the broader delivery standard.

1. Literal statement

We run delivery through defensible plans, visible ownership, honest systems of record, and explicit change control.

2. Why it exists

Most preventable delivery pain comes from weak planning, invisible drift, and soft ownership rather than from the underlying work being hard.

PM discipline exists to:

  • make commitments defensible
  • keep risk visible
  • create control under pressure
  • make delivery legible to clients and leadership

3. Analogy

The strongest analogies here are:

  • Consultancies — strategy and delivery should survive scrutiny before leaders bet on them
  • Banks and risk-managed systems — control matters because unmanaged drift compounds

This is not about bureaucracy for its own sake. It is about dependable execution.

4. What good looks like

  • dates that are pressure-tested before they are treated as real
  • explicit dependencies with owners
  • milestones that mean something to the client
  • visible ownership throughout the system
  • early surfacing of risk
  • re-review when assumptions change materially

5. Planning doctrine

5.1 Plan before promise

Major dates should appear in the SOW ↔ project plan and pass Project Review Meeting before they are treated as hard external commitments.

5.2 Dependencies explicit

Dependencies should not be left implicit. Data access, legal review, third-party vendors, client approvals, internal platform constraints, and staffing assumptions should each have:

  • an owner
  • an expected date
  • a visible impact if missed

5.3 Defensible planning

A good plan is not a list of wishes. It is a sequence that can be explained, defended, and revised when assumptions change.

6. Execution doctrine

6.1 Milestone mindset

The client should experience progress through milestones and outcomes, not through internal task sprawl.

6.2 Ownership visible

Work should have visible owners. Ambiguity is allowed in discovery; it is not allowed to persist in execution.

6.3 Systems of record reflect reality

The board, the plan, and the client story should stay aligned closely enough to govern the work.

7. Reporting doctrine

7.1 Linear + narrative

Board state should match the story the CSO tells in weekly touchpoints.

7.2 Risk forward

Yellow flags should appear before red ones. A mature delivery system is not one without issues; it is one where issues are surfaced before they become surprises.

7.3 Honest status over status theater

The purpose of status is to support decisions, not to create the appearance of motion.

8. Change control and re-gating

8.1 Material change triggers review

Scope creep, major dependency shifts, meaningful feasibility changes, and timeline drift should trigger visible review rather than being quietly absorbed.

8.2 Re-gate when assumptions change

If the plan’s assumptions are no longer true, the team should refresh the plan and route it back through the appropriate review path.

8.3 Do not preserve false commitments

The system should not protect dates just because they were previously stated. It should protect credibility by naming the truth early.

9. Common misses

  • committing on optimism rather than pressure-tested planning
  • tracking internal activity without client-meaningful milestones
  • allowing dependencies to stay vague
  • allowing the plan, board, and story to drift apart
  • absorbing material scope or timing changes without resetting the plan

Last updated: 2026-03-24

Graph View

Backlinks