Designing the type list

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…

In this module: Module 7 · Project Types

1. 1What a project type governs
2. 2Project type classes
3. 3Designing the type listFree preview
4. 4Creating a project type
5. 5Burdening options
6. 6Capitalization options
7. 7Classifications
8. 8Expenditure type class controls
9. 9Billing and other options
10. 10Proving the type works
11. 11What breaks
12. 12Lab: five behavioural patterns and a stakeholder to answer