Hi, I am Adolfo Villafiorita.
I am the co-founder of Shair.Tech,
an innovative-- a socially-vocated
innovative startup in Italy.
Today I'm gonna talk about the way in which
we use Org mode to budget our projects.
First, I need to introduce the way
in which we build our project budget.
We start from the goals
and the work to be performed,
and we split it into different tasks
which may be grouped in different ways,
according to our needs.
It could be user stories or functional groups
or packages, and then for each task,
we compute the effort.
Then from the effort,
we derive the project cost and price
according to two different approaches.
The first approach:
we allocate the effort to each resource
and we multiply the effort of the resource
by the price of the results.
We sum all the efforts together,
and then we sum all the tasks together,
the prices of all the tasks together.
In the second approach,
we use a generic effort estimation
for each task, without allocating the effort
to any specific person,
and we multiply this effort
by the average price of the resource.
In both cases, the price is computed
by summing cost to overheads and profit.
We're a small company.
We can choose our toolchain.
So we decided to use Org mode
for writing our proposals.
We built a template.
The template has got a fixed structure
which allows us to do a lot of reuse,
and some Emacs Lisp code
and Org mode features
to build the project tables.
Let me show you, without further ado,
the template which is shown here.
Basically it is a fairly standard
Org mode document.
There are some sections here.
Let me show you the structure here.
There are some sections,
some of which are not exported /
shown to the client,
because they are of no interest to them,
such as, for instance,
the plaintext of each
ledger accounting entries
we generate for the project
or some info about the detailed budget data,
while others are shared with the clients
to form a project proposal.
Now the structure is not really important
in the sense that the only constraint
and requirement we set
is that there has to be a section
with an ID named plan,
which will contain the project plan.
Here, for instance, we have a project plan
made of a user story
whose development is split into
three different tasks.
For each task, let me show you
just the structure
before the application of the template.
For each task, you need to define the effort.
Here, for instance, we have an effort,
a generic effort not allocated to any person.
We use Org mode duration,
60 stands for 60 minutes,
and here we have an effort profile.
So in task 1.2, Adolfo will work 10 days
and Michele 20 days.
These are working days,
so one working day
corresponds to eight hours.
This is standard. We might revise these
to become more compliant
with the definition given by Org mode.
Notice that you can or cannot,
you may or may not use TODO keywords here,
if you want. We don't usually use them
because the final document
looks nice to the customer without TODO.
We then add them when we move to
a later stage.
So once you define the plan
with the effort allocation,
you can go back to the Emacs Lisp part
where you can set three different variables
to define the hourly rates of your team.
So for instance, here I am taking
10 euros per hour
(not real rate, actually), and Michele at 20.
And then you can set the profit
as a percentage on top of the hourly rate
and profit as a percentage
on top of hourly rates.
The ballpark effort allocation here
is used to compute the average tariff,
our average hourly rate,
as a weighted average.
So here I'm saying that on average,
I will work 30% of the effort of each task,
while Michele will take care of
the remaining 70%, and the hourly rate
is computed by multiplying
30% by 10 + 70% by 20.
If I do a C-c C-c here, I execute
the Emacs Lisp code
in the source code block.
As you can see,
Emacs put back the properties
that transform the effort
into a total amount:
namely, the effort is first transformed
into working hours,
the rates and costs are computed,
overhead computed,
and everything contributes
to the total amount.
Same thing here.
The cost is slightly more complex
because we use profiled effort,
and so on and so forth.
This information here
can be then grouped up
to form the project plan
and project budget.
As you can see,
this is something we do not export
in the project proposal to the client,
because we prefer to do
some rounding by hand
in order to build a budget
which is, let's say, more reasonable.
This table here computes VAT
on total amounts by C-c C-c once again.
Then this table here, the payment structure
is used to compute the amount to be paid
according to the different payments
we want to set in the project.
Here, for instance, we are setting
three payments with the following percentages,
and the table, you set the dates and amounts,
and the table keeps track of the rest
by looking at the total amount
it finds here in the budget table,
so the payment structure and budget
are then used by this piece of code here
to build the entries
used for our internal accounting,
which is based on hledger.
We did everything here by hand,
but it is not necessary, of course,
because if you export the document
using C-c C-e and then, for instance,
l for LaTeX and p for PDF,
Org mode takes care of evaluating
each piece of code in the document
and generate the updated documents.
Here, for instance, you can see
that the PDF generated from the template
which contains all the tables, budget,
and payment schema, everything,
which we use to make an offer
to our clients.
There are various advantages,
the first, the main one being that
we keep all the information in one place,
and that we can version
the different versions.
You can use source control
to version different iterations
on the document.
If you want, you can find the document here.
Thank you for your attention,
and I'm open to questions.
[captions by sachac]