Project Launcher connects the cabinet, team and delivery model
Choose Create project from the cabinet overview. Project Launcher first reads the current workspace, checks whether saved teams are available and asks only the decisions that change the workflow. It does not create a second copy of the same team just because this project uses different delivery settings.
A project's total duration is independent from its sprint cadence. A one-year project may use weekly sprints; a short project may use a two-week planning window. Collty stores cadence, time tracking, cost tracking, billing and invoicing as explicit project rules.
The first choices depend on the workspace
| Workspace | Project relationship | Team choices | What happens next |
|---|---|---|---|
| Client Office | Internal, external or hybrid team | Use a saved team, create an internal team, find an external team, or keep an internal core and fill its gaps with AI | Hybrid always opens Teams Canvas first; AI-only external search can open Project Architect |
| Team Studio | Internal, client or hybrid project | Use a saved team, create a team, use AI-assisted planning, or complete an owned core with external specialists | A client project requests the client email; internal and hybrid ownership remain explicit in the project record |
| Pro Workspace | Project participation | Specialists join or work in projects created by an authorized owner | The specialist workspace does not expose the owner-only Project Launcher |
Create a project from Client Office
- 1Choose Internal team
Use this when the work is delivered by your own team. Choose an existing internal team or create it in My Teams before continuing.
- 2Choose External team
Use this when the project needs a saved external team or a new AI-matched team. The AI option is intentionally unavailable for an internal-only team path.
- 3Choose Hybrid team
Use this when you want to keep yourself, colleagues or an internal team and ask AI to find only the missing project competencies. Existing core opens saved teams; Create core starts a new private team with you as its first member.
- 4Select the team source
Existing opens the saved-team path; Create opens the internal team builder; Find with AI starts external team matching.
- 5Set project rules
Choose sprint duration, hours, costs, billing and invoices for this project. These choices can differ from the team's defaults without creating a duplicate team.
- 6Build the team before the plan
For Hybrid, Collty carries the intent into Teams Canvas. Choose or create the core, run gap-aware AI assembly, review and save one team, then continue to Project Architect.
Create a project from Team Studio
- 1Choose Internal project
Use your own organization as the project relationship. Select or create the delivery team, then choose the project operating rules.
- 2Choose Client project
Use this for work delivered to a known client. Select the team and provide the client email in the guided project flow.
- 3Choose Hybrid project
Use this when an owned team forms the delivery core and external specialists are needed for uncovered roles, expertise or capacity.
- 4Use an existing team when possible
Open a saved private team and launch from that team. This preserves its membership, rates, availability and ownership.
- 5Create or duplicate a team when the composition is new
Save the team first, then continue to project launch. Duplicating is appropriate only when the actual team composition must become a separate reusable team.
- 6Continue to Architect after the team is ready
Hybrid projects open Teams Canvas first. After the team is saved, use Project Architect to review phases, roles, dependencies and any project-specific multi-team composition before activation.
Understand the team-source actions
| Action | Use it when | Result |
|---|---|---|
| Existing | The right team is already saved | Opens the team-selection path without changing the source team |
| Create | Your own delivery team does not exist yet | Opens My Teams to create and save a reusable team before project launch |
| Find with AI | The project needs external capability | Opens AI team matching or Architect team search with the project context |
| Existing core + AI | The right internal team is already saved | Opens the team library, locks the selected core and recommends only missing capability |
| Create core + AI | The hybrid team does not exist yet | Starts with your professional profile, lets you add colleagues and then recommends only missing capability |
| All workflows | The project needs a complex, hybrid or creative-first route | Shows the full guided paths, including Architect and Creative Canvas |
Configure delivery as separate controls
| Control | Options | What changes |
|---|---|---|
| Sprint duration | 1 week, 2 weeks, 1 month | Calendar periods, task grouping, progress review and scheduled reporting |
| Continuous flow | Available in the relevant full workflow | Removes fixed sprint boundaries while keeping project start and task dates |
| Time tracking | Required, optional, off | Whether task-hour fields appear and whether a task can be saved without hours |
| Cost tracking | On or off | Whether existing team rates contribute to task cost, capacity and commercial analytics |
| Billing basis | None, hourly, fixed, milestones | How commercial value is represented for the project |
| Invoices | Off, manual, automatic | Whether invoice controls exist and how invoice records enter the workflow |
Collty prevents contradictory combinations
- Hourly billing requires task hours and cost tracking, so Time tracking cannot be Off.
- Billing None forces Invoices Off because there is no billable basis to invoice.
- Fixed and Milestones use manual invoicing; automatic sprint invoices are reserved for the hourly model.
- Cost tracking may be enabled for an internal project even when Billing is None and Invoices are Off.
- Time tracking can be Optional for a fixed or milestone project when hours are useful operational evidence but not the billing basis.
Sprint duration is not project duration
| Cadence | Boundary | Best for |
|---|---|---|
| 1 week | A calendar-week planning and reporting rhythm | Fast-moving delivery and frequent review |
| 2 weeks | One 14-day sprint | Larger commitments that need fewer planning resets |
| 1 month | One monthly delivery period | Longer operational or retained work |
| Continuous | No fixed sprint boundary | Flow-based work where tasks move independently |
Team defaults accelerate setup without locking the project
Team settings provide sensible starting values for cadence, hours and commercial work. Project Launcher copies the selected values into the project policy, where they become the authoritative rules for that project.
This lets one saved team run an internal project without hours and, separately, a client project with weekly hours and invoices. The team remains one team; each project preserves its own operating model.
The operating model changes the whole project system
| Surface | What adapts |
|---|---|
| Project Workspace | Sprint or flow labels, task-hour fields, hour validation and delivery-period navigation |
| Project Architect | Task-hour allocation, modeled cost, budget realism and team workload |
| Creative Canvas | Task objects and workspace sync include hours only when the project allows them |
| Project Analytics | Sprint or timeline language, accepted allocations, workload, rates, financial cards and invoice access |
| Project details | Specialist HOURS, expenses and invoice panels appear only when the project capabilities require them |
| AI agents | Operating rules read the same project cadence and commercial capabilities before interpreting project evidence |
Set a real project schedule before creation
Project Launcher requires a planned start before it creates a project. Projects Canvas then shows the same schedule as a visual line with Start, Today, Target finish and Calculated finish, so timing is visible without opening a separate form.
A target date never removes planned work. When the accepted specialist hours need more time than the target allows, Collty keeps the hours, shows a schedule conflict and uses the later calculated finish as the project planning boundary.
| Operating model | Required at creation | How finish is resolved |
|---|---|---|
| Fixed scope with hours | Planned start | The longest specialist allocation determines the minimum duration because specialists can work in parallel. A later target may extend it. |
| Retainer with fixed horizon | Planned start and planned finish | Hours remain monthly allocation; the selected horizon defines the calendar range. |
| Ongoing retainer | Planned start and Ongoing | The calendar shows an active continuing range without inventing a deadline. |
| Hours disabled | Planned start and planned finish | No hour-based duration is calculated; the explicit delivery horizon is used. |
Review before activation
- 1Confirm the relationship
Check internal versus external/client project and, for Team Studio client work, verify the client email.
- 2Confirm the team
Make sure the selected specialists are the active project composition, not merely everyone available in the wider source team.
- 3Confirm schedule
Set the planned start and review the calculated or explicit finish. Resolve any capacity conflict before activation.
- 4Confirm hours and costs
Enable only the fields the team will actually maintain. Required hours become a save-time rule for project tasks.
- 5Confirm billing and invoices
Check that the commercial basis and invoice mode match the agreement before project activation.
- 6Continue and review the draft
Project Launcher prepares the shortest valid path. You can still review the team and project structure before making the project active.