The mistake everyone makes: a project type per department, per service line, or per client segment. Now there are forty types with identical behaviour and nothing gained.
WHAT BEHAVES DIFFERENTLY? The right question. Does this group of projects burden differently, capitalize, bill differently, or permit different transaction classes? If not, it is not a type — it is a classification or a report attribute.
The typical shape: three to eight types. Contract billable. Contract fixed-price, if the billing genuinely differs. Capital. Internal indirect. And perhaps a bid or pre-sales type.
What belongs elsewhere. Service line, practice, region → classifications. Client segment → classifications, or the contract. Reporting groupings → classifications.
CLASSIFICATIONS ARE THE RELEASE VALVE. And here is where this module answers a question from four modules ago. This is the answer to the PMO director from Module 3 who wanted six project units. Practice differentiation lives in a classification — visible in every report, with none of the structural cost. Same stakeholder, same request, arriving in a new form: now he wants six project types. The answer is the same object, and Lesson 7 builds it.
The workshop questions. Which projects burden differently? Which produce assets? Which are billed — and are the billing mechanics genuinely different? Which need to prevent certain transaction types? And: what else do you want to distinguish — and is it behaviour, or is it reporting? That last question is the whole lesson in one sentence, and it is the one to ask out loud in the room.