Skip to content

Commit

Permalink
Merge pull request #5 from root-systems/draft-v3
Browse files Browse the repository at this point in the history
update model
  • Loading branch information
Daniel Lewis authored Aug 13, 2017
2 parents f6fd9e5 + 3179d4b commit 6136c5b
Showing 1 changed file with 55 additions and 48 deletions.
103 changes: 55 additions & 48 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,102 +1,109 @@
# Financial Agreement

## Dependancies
This agreement is dependant on three others:
## Dependencies
This agreement is dependent on three others:

- [Activity Types Agreement](https://www.rootsystems.nz/agreements/activity-types.html)
- [Cordination Agreement](https://www.rootsystems.nz/agreements/coordination-agreement.html)
- [Self Management Agreement](https://www.rootsystems.nz/agreements/self-management.html)
- [Buffer Agreement](https://www.rootsystems.nz/agreements/buffer-agreement.html)

## Member Remuneration
Our simplified formula for a months pay can be described as:
Our simplified formula for a month's pay can be described as:

**Base Income + Business Viability Bonus + Performance Bonus**

- **Base Income:** This is the monthly amount a core member will always receive, no matter what number of hours they work.
- **Business Viability Bonus:** A top up amount that based on how sustainable we percieve our business to be.
- **Business Viability Bonus:** A top up amount that is based on how sustainable we perceive our business to be.
- **Performance Bonus:** A top up based on work that brings money to organisation.

How we generate these different amounts is a little more complex as it depends on two factors:
How we generate these different amounts is a little more complex as it depends on two factors:

- Our current Buffer level
- Our current Buffer Level
- Activity Types conducted during the month

We use activity types and buffer levels to determine what amounts are added to these three components:
We use Activity Types and Buffer Levels to determine what amounts are added to these three components:

Variables:

- COR - Charge-out rate (How much a member costs per hour to the client)
- BH - Billable hours (number of billable hours a member billed to a client in a month)
- COR - Charge-out rate: How much a member costs per hour to the client
- BH - Billable hours: Number of billable hours a member billed to a client in a month
- COM - Commission = 20%
- Day Activity Types:
- Personal - only basic income
- Internal investment or administration - basic income + an internal top up for the day
- Contracting - basic income + a contracting top up for the day + BH \* COR \* 10%
- Buffer:
- Personal: Covered by monthly basic income
- Team: Days the member is acting/working for the team - paid a day rate based on buffer
- Contracting: Top up for hours worked on Team days that bring money to the group - BH \* COR \* COM
- Buffer:
- Level 1
- Level 2
- Level 3
- Level 4
- Commission = 10%


### The Formula
To calculate the amount someone recieves, take their booked in activity types for a month and refer to the table below.
To calculate the amount someone recieves, take their active days for a month and refer to the table below.

### Calculating daily amounts
| Buffer level | Personal | Internal Top up | Contracting Top up|
| :--- | ---: | ---: | ---: |
| Level 0 | 100 | 160 | 200 |
| Level 1 | 100 | 190 | 240 |
| Level 2 | 100 | 220 | 280 |
| Level 3 | 100 | 250 | 320 |
| Level 4 | 100 | 280 | 360 |
| Buffer Level | Day Rate | Contracting Rate |
| :--- | ---: | ---: |
| Level 0 | 100 | COM * COR * BH |
| Level 1 | 150 | COM * COR * BH |
| Level 2 | 200 | COM * COR * BH |
| Level 3 | 250 | COM * COR * BH |
| Level 4 | 300 | COM * COR * BH |

### Day rate adjustment
To provide members flexibility we ask members to self-describe how much they feel they worked according to team expectations. Members book in and update "day descriptions" to denote their intent and actual work::

- **Short day:** 0.5
- **Full day:** 1.0
- **Long day:** 1.25

### Forcasting example
Members will denote what type of day they plan to work and update it to what was actually worked.

Given we are planning for febuary of a non leap year
### Forcasting example
Given we are planning for February of a non-leap year (28 days, 20 weekdays, 8 weekend days)
And we are at Buffer Level 2
And a Member has booked in:
And a member has booked in:

- 4 Personal days
- 6 Internal days
- 10 Contracting days

And we can estimat:
- 16 Team days

- 6 billable hours contracting day
And we can estimate:

- 6 billable hours per day for 10 of the days
- a charge out rate of $140

When we run a cashflow forecast
Then we can calculate the member will recieve:


4 * 100
4 * 220
10 * 280
60 * 0.1 * 100
----------------
Total: 5120
1 * $1500
+ 16 * $200
+ 60 * 0.2 * $140
----------------
Total: $6380

### End of Month
At the end of a month we produce the invoices for our members. This follows the same process as forecasting except that we substitute in the actual billable hours worked and charge out rate.

### !Important (very experimental)
We do not adjust peoples pay down because of changes to their schedule. eg if a person gets sick and can't work we don't demote their days to a personal type. We will adjust people's pay up if they have had to do extra days they didn't intend to.
At the end of a month we produce the invoices for our members. This follows the same process as forecasting except that we substitute in the actual billable hours worked, and the charge out rate.

It is the job of the [Coordinators](https://www.rootsystems.nz/roles/coordinator.html) to keep an eye on this overtime and checkin with the group and members about how things are going. A transparent monthly report will be shared to all members.

### Buffer as control lever (What's the point of all this?)
By coupling several factors to buffer events we can create a self regulating system. The intent is that as the buffer increases so to does the money flowing away from the pod. These are the scaling money outflows and do not include fixed costs such as space hire and SaaS tools.
By coupling several factors to buffer events we can create a self-regulating system. The intent is that as the buffer increases, so too does the money flowing away from the pod. These are the scaling money outflows and do not include fixed costs such as space hire and SaaS tools.

### Buffer level amount
A buffer level is defined as $4,000 per person as per the [buffer agreement](https://www.rootsystems.nz/agreements/buffer-agreement.html)

## Contribution to a commons
Contribution to a commons is done as a percentage of total revenue of the pod per month. Unless agreed otherwise this is a scaling amount of between 0-8% depending on the buffer level.
Contribution to a commons is done as a percentage of total revenue of the pod per month. Unless agreed otherwise this is a scaling amount of between 0-8% depending on the Buffer Level.

## Collaborative funding
Giving individuals control over a discretionary amount of organisation funds that they (by themselves or with others) can use for a business expense they identify. eg new computer, desk, coffee machine, plants etc...
Giving individuals control over a discretionary amount of organisation funds that they (by themselves or with others) can use for a business expense they identify. e.g. new computer, desk, coffee machine, plants etc...

## Invoicing
Invoices to our customers are sent within the first 5 days of the month following the billing month. Invoices are sent via Xero.

## Reporting
## Reporting
A cashflow report is published at the end of each month.

# Glossary
Expand All @@ -114,13 +121,13 @@ We manage and deliver a project that is extending/refining an existing code base
We manage and deliver a project with a new code base.

#### Technical Discovery workshops/Code audits
Typically a days work these are tools we use to deepen our and the client's understanding of the requirements.
Typically a day's work, these are tools we use to deepen ours and the client's understanding of the requirements.

#### Retainers/Maintenance Agreements
A fixed monthly sum paying for us to update, refactor and slowly develop the code base.

## Expenses
Money flowing away from the pod happens as follows
Money flowing away from the pod happens as follows:

#### Fixed costs
Paying for our operation cost has the highest priority and happens before paying individuals.
Expand All @@ -132,5 +139,5 @@ Paying for contractors by the hour.
Eating together

#### Basic Income
All members recieve $100 a day (5 days/week) all year. Regardless of what activities you conduct.
All members recieve $100 a day (5 days/week) all year. Regardless of what activities they conduct.

0 comments on commit 6136c5b

Please sign in to comment.