WEBVTT
00:01.040 --> 00:00:02.800
Hi, I am Adolfo Villafiorita.
00:00:02.800 --> 00:00:04.799
I am the co-founder of Shair.Tech,
00:00:04.799 --> 00:00:07.200
an innovative-- a socially-vocated
00:00:07.200 --> 00:00:10.558
innovative startup in Italy.
00:00:10.559 --> 00:00:13.280
Today I'm gonna talk about the way in which
00:00:13.280 --> 00:00:17.680
we use Org mode to budget our projects.
00:00:17.680 --> 00:00:19.039
First, I need to introduce the way
00:00:19.039 --> 00:00:21.279
in which we build our project budget.
00:21.279 --> 00:00:22.480
We start from the goals
00:00:22.480 --> 00:00:24.720
and the work to be performed,
00:24.720 --> 00:00:29.840
and we split it into different tasks
00:29.840 --> 00:00:31.920
which may be grouped in different ways,
00:31.920 --> 00:00:33.440
according to our needs.
00:00:33.440 --> 00:00:36.800
It could be user stories or functional groups
00:00:36.800 --> 00:00:40.719
or packages, and then for each task,
00:00:40.719 --> 00:00:44.000
we compute the effort.
00:44.000 --> 00:00:45.440
Then from the effort,
00:00:45.440 --> 00:00:49.840
we derive the project cost and price
00:49.840 --> 00:00:52.239
according to two different approaches.
00:52.239 --> 00:00:53.280
The first approach:
00:00:53.280 --> 00:00:56.320
we allocate the effort to each resource
00:56.320 --> 00:00:59.680
and we multiply the effort of the resource
00:00:59.680 --> 00:01:01.359
by the price of the results.
00:01:01.359 --> 00:01:04.320
We sum all the efforts together,
00:01:04.320 --> 00:01:07.280
and then we sum all the tasks together,
00:01:07.280 --> 00:01:09.600
the prices of all the tasks together.
00:01:09.600 --> 00:01:11.200
In the second approach,
00:01:11.200 --> 00:01:16.400
we use a generic effort estimation
00:01:16.400 --> 00:01:20.799
for each task, without allocating the effort
00:01:20.799 --> 00:01:22.560
to any specific person,
00:01:22.560 --> 00:01:25.119
and we multiply this effort
00:01:25.119 --> 00:01:29.040
by the average price of the resource.
01:29.040 --> 00:01:34.720
In both cases, the price is computed
01:34.720 --> 00:01:40.079
by summing cost to overheads and profit.
00:01:40.079 --> 00:01:41.040
We're a small company.
00:01:41.040 --> 00:01:42.719
We can choose our toolchain.
00:01:42.720 --> 00:01:44.960
So we decided to use Org mode
00:01:44.960 --> 00:01:47.360
for writing our proposals.
01:47.360 --> 00:01:49.200
We built a template.
00:01:49.200 --> 00:01:54.159
The template has got a fixed structure
01:54.159 --> 00:01:56.880
which allows us to do a lot of reuse,
01:56.880 --> 00:01:59.600
and some Emacs Lisp code
00:01:59.600 --> 00:02:01.040
and Org mode features
00:02:01.040 --> 00:02:04.079
to build the project tables.
00:02:04.079 --> 00:02:07.600
Let me show you, without further ado,
00:02:07.600 --> 00:02:11.760
the template which is shown here.
02:11.760 --> 00:02:15.520
Basically it is a fairly standard
02:15.520 --> 00:02:17.750
Org mode document.
02:20.800 --> 00:02:23.760
There are some sections here.
02:23.760 --> 00:02:28.879
Let me show you the structure here.
02:28.879 --> 00:02:30.000
There are some sections,
00:02:30.000 --> 00:02:34.959
some of which are not exported /
00:02:34.959 --> 00:02:36.640
shown to the client,
02:36.640 --> 00:02:39.519
because they are of no interest to them,
02:39.519 --> 00:02:41.040
such as, for instance,
00:02:41.040 --> 00:02:43.280
the plaintext of each
00:02:43.280 --> 00:02:45.440
ledger accounting entries
02:45.440 --> 00:02:47.440
we generate for the project
02:47.440 --> 00:02:53.680
or some info about the detailed budget data,
00:02:53.680 --> 00:02:56.319
while others are shared with the clients
00:02:56.319 --> 00:02:58.399
to form a project proposal.
00:02:58.400 --> 00:03:00.400
Now the structure is not really important
00:03:00.400 --> 00:03:02.720
in the sense that the only constraint
00:03:02.720 --> 00:03:05.360
and requirement we set
00:03:05.360 --> 00:03:07.599
is that there has to be a section
03:07.599 --> 00:03:10.800
with an ID named plan,
03:10.800 --> 00:03:15.840
which will contain the project plan.
03:15.840 --> 00:03:21.040
Here, for instance, we have a project plan
00:03:21.040 --> 00:03:23.599
made of a user story
03:23.599 --> 00:03:25.360
whose development is split into
00:03:25.360 --> 00:03:27.360
three different tasks.
03:27.360 --> 00:03:30.080
For each task, let me show you
00:03:30.080 --> 00:03:33.200
just the structure
00:03:33.200 --> 00:03:37.279
before the application of the template.
03:37.280 --> 00:03:45.200
For each task, you need to define the effort.
00:03:45.200 --> 00:03:47.360
Here, for instance, we have an effort,
00:03:47.360 --> 00:03:50.480
a generic effort not allocated to any person.
03:50.480 --> 00:03:52.400
We use Org mode duration,
00:03:52.400 --> 00:03:54.799
60 stands for 60 minutes,
03:54.799 --> 00:03:57.680
and here we have an effort profile.
00:03:57.680 --> 00:04:02.000
So in task 1.2, Adolfo will work 10 days
00:04:02.000 --> 00:04:04.159
and Michele 20 days.
04:04.159 --> 00:04:06.000
These are working days,
00:04:06.000 --> 00:04:07.439
so one working day
00:04:07.439 --> 00:04:09.760
corresponds to eight hours.
04:09.760 --> 00:04:13.519
This is standard. We might revise these
04:13.519 --> 00:04:15.040
to become more compliant
00:04:15.040 --> 00:04:19.759
with the definition given by Org mode.
00:04:19.759 --> 00:04:23.040
Notice that you can or cannot,
00:04:23.040 --> 00:04:26.720
you may or may not use TODO keywords here,
00:04:26.720 --> 00:04:29.199
if you want. We don't usually use them
00:04:29.199 --> 00:04:31.360
because the final document
00:04:31.360 --> 00:04:34.720
looks nice to the customer without TODO.
00:04:34.720 --> 00:04:38.479
We then add them when we move to
00:04:38.479 --> 00:04:40.719
a later stage.
04:40.720 --> 00:04:43.040
So once you define the plan
00:04:43.040 --> 00:04:45.600
with the effort allocation,
04:45.600 --> 00:04:51.440
you can go back to the Emacs Lisp part
00:04:51.440 --> 00:04:55.680
where you can set three different variables
04:55.680 --> 00:04:59.680
to define the hourly rates of your team.
04:59.680 --> 00:05:02.880
So for instance, here I am taking
00:05:02.880 --> 00:05:06.160
10 euros per hour
00:05:06.160 --> 00:05:09.680
(not real rate, actually), and Michele at 20.
05:09.680 --> 00:05:11.360
And then you can set the profit
00:05:11.360 --> 00:05:14.560
as a percentage on top of the hourly rate
00:05:14.560 --> 00:05:16.160
and profit as a percentage
00:05:16.160 --> 00:05:19.360
on top of hourly rates.
05:19.360 --> 00:05:24.000
The ballpark effort allocation here
00:05:24.000 --> 00:05:28.880
is used to compute the average tariff,
05:28.880 --> 00:05:32.160
our average hourly rate,
05:32.160 --> 00:05:33.600
as a weighted average.
00:05:33.600 --> 00:05:36.320
So here I'm saying that on average,
00:05:36.320 --> 00:05:40.639
I will work 30% of the effort of each task,
00:05:40.639 --> 00:05:42.400
while Michele will take care of
00:05:42.400 --> 00:05:47.280
the remaining 70%, and the hourly rate
00:05:47.280 --> 00:05:48.720
is computed by multiplying
00:05:48.720 --> 00:05:57.120
30% by 10 + 70% by 20.
05:57.120 --> 00:06:00.880
If I do a C-c C-c here, I execute
00:06:00.880 --> 00:06:05.440
the Emacs Lisp code
00:06:05.440 --> 00:06:07.439
in the source code block.
00:06:07.440 --> 00:06:08.880
As you can see,
00:06:08.880 --> 00:06:15.759
Emacs put back the properties
06:15.759 --> 00:06:17.840
that transform the effort
00:06:17.840 --> 00:06:19.600
into a total amount:
00:06:19.600 --> 00:06:22.800
namely, the effort is first transformed
00:06:22.800 --> 00:06:24.479
into working hours,
06:24.479 --> 00:06:27.280
the rates and costs are computed,
06:27.280 --> 00:06:28.880
overhead computed,
00:06:28.880 --> 00:06:32.160
and everything contributes
00:06:32.160 --> 00:06:34.639
to the total amount.
06:34.639 --> 00:06:37.600
Same thing here.
00:06:37.600 --> 00:06:41.440
The cost is slightly more complex
00:06:41.440 --> 00:06:45.360
because we use profiled effort,
06:45.360 --> 00:06:47.199
and so on and so forth.
00:06:47.199 --> 00:06:49.680
This information here
00:06:49.680 --> 00:06:56.960
can be then grouped up
06:56.960 --> 00:06:59.759
to form the project plan
00:06:59.759 --> 00:07:01.599
and project budget.
00:07:01.599 --> 00:07:03.039
As you can see,
07:03.039 --> 00:07:06.880
this is something we do not export
07:06.880 --> 00:07:09.440
in the project proposal to the client,
07:09.440 --> 00:07:10.880
because we prefer to do
00:07:10.880 --> 00:07:13.199
some rounding by hand
07:13.199 --> 00:07:14.880
in order to build a budget
00:07:14.880 --> 00:07:20.880
which is, let's say, more reasonable.
07:20.880 --> 00:07:24.639
This table here computes VAT
00:07:24.639 --> 00:07:28.159
on total amounts by C-c C-c once again.
00:07:28.160 --> 00:07:31.120
Then this table here, the payment structure
00:07:31.120 --> 00:07:36.080
is used to compute the amount to be paid
00:07:36.080 --> 00:07:39.280
according to the different payments
00:07:39.280 --> 00:07:40.800
we want to set in the project.
00:07:40.800 --> 00:07:42.160
Here, for instance, we are setting
00:07:42.160 --> 00:07:45.919
three payments with the following percentages,
00:07:45.919 --> 00:07:49.199
and the table, you set the dates and amounts,
00:07:49.199 --> 00:07:53.440
and the table keeps track of the rest
00:07:53.440 --> 00:07:56.479
by looking at the total amount
07:56.479 --> 00:08:00.800
it finds here in the budget table,
00:08:00.800 --> 00:08:03.280
so the payment structure and budget
00:08:03.280 --> 00:08:07.280
are then used by this piece of code here
08:07.280 --> 00:08:12.000
to build the entries
00:08:12.000 --> 00:08:16.720
used for our internal accounting,
08:16.720 --> 00:08:21.038
which is based on hledger.
08:21.039 --> 00:08:23.759
We did everything here by hand,
08:23.759 --> 00:08:26.400
but it is not necessary, of course,
08:26.400 --> 00:08:31.280
because if you export the document
00:08:31.280 --> 00:08:34.880
using C-c C-e and then, for instance,
00:08:34.880 --> 00:08:39.760
l for LaTeX and p for PDF,
08:39.760 --> 00:08:43.279
Org mode takes care of evaluating
00:08:43.279 --> 00:08:46.480
each piece of code in the document
00:08:46.480 --> 00:08:50.720
and generate the updated documents.
00:08:50.720 --> 00:08:52.000
Here, for instance, you can see
00:08:52.000 --> 00:08:55.680
that the PDF generated from the template
00:08:55.680 --> 00:08:57.440
which contains all the tables, budget,
00:08:57.440 --> 00:08:59.920
and payment schema, everything,
00:08:59.920 --> 00:09:02.240
which we use to make an offer
00:09:02.240 --> 00:09:07.999
to our clients.
09:08.000 --> 00:09:10.000
There are various advantages,
00:09:10.000 --> 00:09:12.640
the first, the main one being that
00:09:12.640 --> 00:09:15.600
we keep all the information in one place,
09:15.600 --> 00:09:17.920
and that we can version
00:09:17.920 --> 00:09:20.399
the different versions.
00:09:20.399 --> 00:09:21.680
You can use source control
00:09:21.680 --> 00:09:24.640
to version different iterations
00:09:24.640 --> 00:09:26.080
on the document.
09:26.080 --> 00:09:28.000
If you want, you can find the document here.
00:09:28.000 --> 00:09:33.120
Thank you for your attention,
00:09:33.120 --> 00:09:34.120
and I'm open to questions.
00:09:34.120 --> 00:09:37.279
[captions by sachac]
