2.2.3 – Project Financials – Standards

Introduction

At Arcanary, project management is not only about design and documentation — it also requires a rigorous administration framework that guarantees clarity for our clients and control for our internal operations.
To achieve this, we use Business Objects: standardized entities that allow us to organize information, invoice transparently, and ensure traceability of every service delivered.


1. Periods

  • Definition: A period is a time frame used for administration and documentation.
  • Format: Normally corresponds to a month.
  • Naming: Two-digit year + two-digit month, written without separators (e.g., 2509 = September 2025).
  • Purpose: Aligns invoices, activities, and costs consistently across time.

2. Accounts

  • Definition: The account is the entity responsible for paying a project’s invoices.
  • Types:
    • Private individual (e.g., a person).
    • Private group (e.g., a couple or family).
    • Institution/Business (e.g., a developer, contractor, or company).
  • Note: The account may or may not be the principal (the ultimate beneficiary of the project).

3. Projects

  • Definition: The entity that develops the actual work.
  • Characteristics:
    • Linked to a site.
    • Produces deliverables and is divided into terms (A – Analysis, B – Design, etc.).
    • Belongs to an account and to an Arcanary office.
  • Key Fields:
    • Name, code, number, description.
    • Building class, typology, and use.
    • Address.
    • Current term (the most advanced active stage — e.g., a project may be in Construction while still having documents in Council).
    • Type of service (Architecture, Interiors, Modeling, Documentation).
    • Role (Consultant, Lead Consultant, Sub-Consultant).

4. Proposals

  • Definition: A formal or informal communication that presents scope, services, and costs.
  • Types:
    1. Service Proposal (Formal): Full document (often prepared in Google Docs) with stages, timing, deliverables, fee structure, and terms & conditions.
    2. Informal Proposal: Usually an email; provides a brief outline of services or costs, without terms & conditions.
  • Structure:
    • Composed of line items.
    • Each line item corresponds to a deliverable (e.g., schematic design, 3D scan, consulting).
    • Deliverables may be lump sum or hourly rate.
  • Rule: Every invoice must be backed by a proposal.

5. Invoices

  • Definition: The financial document that claims payment for services.
  • Relationships:
    • 1 Invoice → 1 Period.
    • 1 Invoice → 1 Proposal.
    • 1 Proposal → 1 Project.
    • 1 Project → 1 Account.
  • Naming:
    • Automatic Xero code: IN + 4-digit number (e.g., IN0042).
    • Reference field: used as the PDF file name, typically including project code/name.
  • Line Items:
    • Title in ALL CAPS, identical to the proposal line.
    • A brief description underneath (concise, not full scope).
    • Quantity: percentage of claim for that period, expressed from 0 to 1 (0.2 = 20%).
    • Across invoices, all quantities for a line must add up to 1.0 (100%).

6. Missions

  • Definition: Actions or deliverables that structure a project’s work.
  • Types:
    • Package: A curated set of documents issued for a purpose (e.g., DA package with architecture, survey, engineering, SEE).
    • DocDev: Development of documentation or modeling tasks (e.g., site model, existing conditions).
    • Event: Meetings, inspections, milestones. Always require minutes and, if billable, a breakdown of hours.
    • RF (Request): Formal requests such as RFQ (Quotation), RFP (Proposal), RFT (Tender), RFI (Information), RFA (Approval).
  • Role: Provides the framework against which activities can be tracked.

7. Activities

  • Definition: The smallest unit of work — time spent by a team member.
  • Types:
    • A (Admin): Performed by PMs/Office Managers (e.g., phone calls, client meetings, coordination).
    • D (Development): Performed by Members/PMs (design, modeling, documentation), always linked to a mission.
  • Structure:
    • Type (Kickoff, Markup, Response, Portfolio).
    • Subject (title of the activity).
    • Detailed description (internal use only, for PMs/OMs to assess work/time).
    • Start and end time.
    • Can be stored as backlog if not executed immediately.
  • Special Case:
    • All activities must be linked to a project.
    • Non-billable business tasks (e.g., templates, internal admin) are logged under proxy projects.

Relational Map (Quick View)

  • Account → Project → Proposal → Invoice (→ Period)
  • Project → Missions → Activities
  • Events and RFs are subtypes of missions with specific billing rules.

Conclusion

These Business Objects are the backbone of Arcanary’s administrative system.
By defining and using them consistently:

  • Members can log time accurately.
  • Project Managers can link work to proposals and invoices.
  • Office Managers and Administrators can manage billing with clarity.
  • Financial Controllers can evaluate profitability by project and by period.