Practicing the processes I: starting up, directing and initiating

The seven processes describe the journey of a project from its first request to its closure, and the exams test them in two ways. Foundation asks about their purposes, objectives, triggers, activities and outputs. Practitioner asks which process is running in a scenario, who should be doing what, and what should happen next. This lesson covers the three processes that get a project off the ground: starting up a project, directing a project and initiating a project. Lesson 10 covers the four that run and end it. As always, check the exact activity names in your manual before the exam; this lesson uses descriptive wording.

How the processes fit together

A project begins when the business layer issues a project mandate. Starting up a project is a pre-project process that checks whether the project is viable and worthwhile and prepares for initiation. Directing a project runs from the end of starting up until closure and is where the project board makes its decisions. Initiating a project is the first management stage, which builds the foundation for the rest of the project: the project initiation documentation, the project plan and the detailed business case. Controlling a stage, managing product delivery and managing a stage boundary then repeat for each delivery stage, and closing a project ends it.

Starting up a project: revision points

Two points catch candidates. First, the executive is appointed before the project manager, because the executive is accountable and appoints the rest of the team. Second, starting up is deliberately short and light. Its purpose is to stop poorly conceived projects before money is committed to initiation, so a scenario where starting up takes months and produces a detailed plan has probably gone wrong.

Directing a project: revision points

The most frequent Practitioner question about directing asks whether the board is behaving as a board. Boards that approve individual work packages, hold weekly progress meetings to tell the project manager what to do next, or skip stage boundary decisions are not directing by exception. Equally, a board that never gives direction when the project manager asks for advice is failing in its role.

Initiating a project: revision points

Initiation is a management stage with its own stage plan and its own boundary. Near its end, managing a stage boundary prepares the plan for the first delivery stage, so the board can authorize the project and the next stage at the same time. Questions sometimes test this overlap by asking which process produces the first delivery stage plan.

Foundation-style practice

Practitioner-style practice: a new branch project

Scenario extract. Harbor City Libraries' board of trustees has asked the library to open a small branch in a leased storefront in a growing neighborhood. The director of library services, who will be executive, appoints Dev Sharma as project manager. Dev starts by reviewing the lessons report from the makerspace refit and the accessibility upgrade. He drafts a project brief with an outline business case comparing a leased storefront with a mobile library van, and plans a three-week initiation stage. A trustee suggests skipping initiation because 'the lease is already signed and the design is simple'.

The branch's lease must be approved under the library board's delegated authority policy and reported to the city, which funds most of the library's capital budget. In exam terms, the city and the library board are both parts of the business layer, which is why the executive checks the project mandate's constraints before starting up continues.

A matching question on outputs

Timing the decisions

Questions about directing often turn on when a decision is made. The program below lays out Dev's branch project as a sequence of process steps and board decisions, which is a useful study aid: drawing the sequence for each running case makes 'what happens next' questions much easier.

steps = [
    ("project mandate", "business layer", None),
    ("starting up a project", "executive and project manager", None),
    ("authorize initiation", "project board", "decision"),
    ("initiating a project", "project manager", None),
    ("managing a stage boundary (plan stage 2)", "project manager", None),
    ("authorize the project and stage 2", "project board", "decision"),
    ("controlling a stage / managing product delivery", "project manager / team managers", None),
    ("managing a stage boundary (plan stage 3)", "project manager", None),
    ("authorize stage 3", "project board", "decision"),
    ("closing a project", "project manager", None),
    ("authorize project closure", "project board", "decision"),
]
for n, (step, who, kind) in enumerate(steps, 1):
    mark = "  <- board decision" if kind else ""
    print(f"{n:>2}. {step:<50} {who}{mark}")
print(f"board decisions: {sum(1 for s in steps if s[2])}")

 1. project mandate                                    business layer
 2. starting up a project                              executive and project manager
 3. authorize initiation                               project board  <- board decision
 4. initiating a project                               project manager
 5. managing a stage boundary (plan stage 2)           project manager
 6. authorize the project and stage 2                  project board  <- board decision
 7. controlling a stage / managing product delivery    project manager / team managers
 8. managing a stage boundary (plan stage 3)           project manager
 9. authorize stage 3                                  project board  <- board decision
10. closing a project                                  project manager
11. authorize project closure                          project board  <- board decision
board decisions: 4

The sequence shows four board decisions for a project with an initiation stage and two delivery stages. Look at which steps belong to the project manager: preparing the next stage plan in managing a stage boundary always comes before the board's authorization of that stage.

The project brief and the PID

Questions often test the difference between the project brief and the project initiation documentation. The brief is a starting point: it describes the project's background, objectives, outline business case, project product description, delivery approach and the project management team, in enough detail for the board to decide whether to invest in initiation. The PID is the full basis for managing the project: it adds the management approaches, project controls, the project plan, the detailed business case and the tailoring decisions. If a question asks which product the board uses to authorize the project, it is the PID; if it asks which product supports the decision to authorize initiation, it is the brief.