Creating projects in an organisation

Standing up a project for an incoming LBO from the administrator's side — the naming decision you control, and the handover that makes the customer self-sufficient.

Overview

Manage Projects, in the administration area at Org Admin level, is the organisation's inventory of projects — every project in it, and where you create new ones. This is not the deal team's project list.

This is the administrator's view of A2.1. That lesson is for the deal team creating a project they will work in; this one is for whoever provisions it and hands it over.

What you'll learn

Why one project is one LBO, and why you are well placed to enforce it
Who the first member is, and why that grant matters
How to name a project when you are naming it for other people
Why the handover matters as much as the creation

What a project is, from up here

"Projects help you manage investments or transactions by grouping companies, operations, and documents under one initiative."

One project is one LBO (A1.3). So a new project means a new deal — not a new company, and not a new wave.

The most useful thing an administrator can do is enforce that boundary, because a project created per company produces a structure that only fails when you look at it as a whole. An Org Admin receiving a request for "a project for the new ManCo" is the last line of defence against a split structure, and is well placed to refuse it — the person asking may not know it matters.

The first member is the whole handover

A project created by an Org Admin has no members. The act that makes it usable is inviting one person as Project Admin.

That person then invites the rest of the deal team and manages their roles themselves (A2.3), without coming back to us. So this single grant is what makes the customer self-sufficient — and it is the grant to get right, because whoever holds it can extend access to anyone else.

Steps

Open Manage Projects in the administration area.
Select Create Project.
Enter a Project Name. That is the only field — a project centralises the documents, stakeholders and key information for an LBO, and takes no further configuration. There is no fund to choose; funds group projects from their own side and are optional (A2.2).
Create it, then hand it over (below).

Naming it, from an administrator's perspective

You are naming something a dozen people will navigate by, for years, alongside every other project in the organisation. Two habits worth having:

Name the deal, not the company. A project usually ends up named after the platform company, which reads as a company while being the container for several (A1.3). Where the firm has more than one deal in a sector, distinguishing the deal saves confusion.

Be consistent across the organisation. A list where some projects are named after companies, some after sectors and some after vintages is a list nobody can scan. This is the one naming decision an administrator actually controls, and it compounds.

Then hand it over

A project you have created is empty and does nothing. The handover matters as much as the creation:

Invite the Project Admin — one named person who will own membership from here.
Point them at what comes next: adding their colleagues (A2.3), then companies before shareholders, and recorded history before anything looks right (A2.1).

An administrator who creates a project and says nothing has handed over something that looks broken to whoever opens it.

Common problems

The screen mentions a team, or an available team count. Teams were removed from the model; anything still referring to them is residual and should be reported rather than worked around. A project needs no team.

You are asked to create a project for a ManCo. It is a company inside the existing project (A1.3). Push back.

You are asked for a project per wave. Same answer — waves are events inside one project (A8.14).

The deal team says the project is empty and nothing works. Correct. Companies come first (A2.1, A3.1).