path: root/2021/captions/emacsconf-2021-project--budgeting-project-monitoring-and-invoicing-with-org-mode--adolfo-villafiorita--main.vtt

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]