Invoice Approval Process

[ghost]

How can we iterate and improve on this process?

Currently @iteles approves invoices as they come in - is there a way to automate approvals? How do you work out the days are correct? Is it from cross-referencing charliehr for sick/holiday days?

[iteles]

@markwilliamfirth Doesn't look like charliehr has an API from a cursory search, could you please check with Ben if it's on the cards?

Also keen to add a 'product' label of some sort to this repo, as in 'problems that can be/should be considered for solutions within our products'

[ghost]

@iteles the main question is how do you currently work out that the days are correct? I don't actually know how you calculate them at the moment

[iteles]

Aaaaaaaah, my process right now is pretty simple (and stupid): I should use a spreadsheet, but I use my memory instead 🙄

I used to use a combination of events in my calendar when people were off and memory and now I use charliehr and memory.

[ghost]

@iteles if we record all off-days in charliehr would I be able to take this off of your plate? Or is it more complex than that?

[iteles]

Only more complex in that we need to know:

• How many days were in the sprint
• How many of those days each of the contributing developers worked for that sprint
  • Sick days/days off (could come from charlie if this is used diligently)
  • Some developers, particularly front-end, will come into a sprint for a few days to help solve a particular issue and then dive back out and some team members are part-time, e.g. QAs)
• If the developers have had to put in more time than expected in the original budget to a client, was this agreed or not (i.e. is it on us or can we charge the client for the extra time/resources)
• There are also occasionally developers (like @Cleop) that we bring in to projects for free to the client as a learning experience or backup for the existing devs but we still need to track the time they have spent and deduct it from the projects' contribution to overheads

[ghost]

@iteles in that case should we start recording these in a spreadsheet?

[ghost]

@iteles response from engineer at Charlie re api:

We have / had one a while ago but the product has changed a lot and it's no longer maintained
It's something that we will bring back but I'm not sure when

Will ask ben too

[iteles]

@markwilliamfirth Probably. What should really happen is that each person should track their time/days as part of your #302 and then in the short term (before we build this functionality), I can flag the adjustments.

I can almost guarantee that I won't remember/prioritise updating anything more than what I already update O_o

[ghost]

@iteles I don't think it's useful or sustainable to maintain doing it from memory - I think we should be recording this. At the moment the invoice PDFs are the only version of truth for contractor worked days. If the information was in a spreadsheet we could quickly and accurately calculate days worked on a project - contractors wouldn't even need to report the days they worked as we would already have that information. It would eliminate any invoice errors.

[iteles]

@markwilliamfirth Centralising the burden of keeping track of this is counter to what we want people to actually do: estimate, track and be accountable for their time. This is why I mentioned that each individual should be tracking and automating their invoices to us as per your MVP.

As for what should and shouldn't be charged to a client, happy for you to propose what you think is the most efficient solution and use of my time 👍

[ghost]

@iteles people would still track their time, but they would report it to you as PM of the project as things occurred. It would be updated in a centralised spreadsheet, which we would then generate the invoices automatically from, thus removing contractor error. Ultimately part of the point of time is to remove the burden of the individual tracking and adding together chunks of time. So I think it makes sense with what we actually want to do.

It's essentially the same as what we do now, except rather than you calculating it on the go and approving / telling me days it's in a spreadsheet instead.

[iteles]

@markwilliamfirth Are you proposing some form of automation of entering that information into the centralised spreadsheet?

[ghost]

If this spreadsheet is kept up to date:
https://docs.google.com/spreadsheets/d/1HejQid3ZqaIK2iYzsv4SrD40UGWYa7qm1YSvMdcWfME/edit#gid=1068312920

We can automate this further with a half day accuracy

@iteles during your invoice approvals calendar slot could you instead update the resourcing spreadsheet?

[iteles]

I update that spreadsheet on a regular basis (i.e. within 24 hours of a change in plan usually as I refer to it pretty much daily) but I think that the question that this raises is that if we want/can automate this process through this particular spreadsheet, half a day of accuracy is no longer enough for our needs.

As was captured here

(...) for the most part, we use that last hour of the day for QAing and scrum mastering across other projects (the reasoning around this and a mini study of whether it works is probably a good blog topic in and of itself), so it's not a 'free' hour for everyone right now (...)

Which means all of this time functions in hours rather than half days. Seems like we need a bit of a rethink around #363 before we can close this one off!

[rub1e]

New(ish) process is:

• @rub1e looks at each incoming dwyler invoice in the invoicing spreadsheet
  • Adds the corresponding client invoice reference
  • Checks that the days match
  • Flags if anything obvious is wrong
• If invoice passes the first line of defence, @iteles then checks it herself and signs it off
• Now dwyler invoices can be paid.

[rub1e]

@iteles if you approve of the above, can I add it to the handbook and then close this issue?

[iteles]

What I was hoping would come out of this issue was some form of requirements that would be something we could build into Time , but I'm happy to close it for now until we pick up Time.

This is still an inefficient process but I've put a lot of time into it already and we will pick this up in a different context to aid the thinking (not a centralised spreadsheet).

[rub1e]

The tricky thing is that you'd have to have the approval process hook into your invoicing / project planning process, and you'd have to be very granular about it - because if e.g. you have a freelancer and a salaried employee at the same level working in the same sprint, it won't be easy to approve the freelancer invoice unless the client invoice splits everything out.

Anyway, let's discuss when Time reappears (exciting times!)