Who pays for the development/maintenance of the components/framework?

Question

We use components and frameworks for the development of our projects. We have third-party components/frameworks (both - closed and open source) and inherited elements on top of them. Sometimes our client requires to develop software that includes adding new features to those components and frameworks - in such cases it is crystal clear - we ask 100% payment for the development/adaptation/improvement costs of those components and frameworks.

But then there are cases when we discover that some component has bug in it and it prohibits to complete the commissioned development task. Sometimes it is more heavy - we can discover the design failure in our framework that involves even redesign/rework some parts of it. Of course, we do and complete such fixings, but they are quite costly, the development costs are not negligible. My question is - how to report to the management such works and how to bill such development works to the client? From the one side - such works were required by the commissioned development works. From the other side - these works can be considered also as: 1) company investments (so, client can not be billed directly); 2) losses due to the technical debt (and client also can not be billed).

Actually - it would be nice to put this into the wider picture how development works are billed and reported. E.g. - what about the accounting of the developer work which is spent for the communication with the client regarding the content of some features. What about the time for meetings with the client. What to do about the time which is required by the developer to assimilate the design and codebase from the previous developers? There are guidelines about cost estimation but little about how to account those costs (investment vs operational costs) and how to report them to the management and client?

Answer 1

In my view, any necessary labor that was exhausted in order to build the finished product or provide a service deliverable would be chargeable to that project as a direct expense. The test would be, would an employee perform the questionable task if it were not for the product being produced? If the answer is no, then it should be a direct expense to the project. It would be an indirect expense if the labor would have been expended no matter what, thus benefiting many projects and clients. There are always exceptions and caveats and nuance so I am sure someone could cite an example of something that may not exactly fit my test, so a general rule but evaluated on a case by case basis would be advised.

As to your second question, all of those supporting and indirect tasks would / should be built into your work estimate of the main task. So if you plan on, say, six hours of direct effort to hammer a set of nails, you might build in one or two more hours for reporting, talking with the client, reporting to your boss, staring at the nail you cannot reach with your hammer, etc.

A caveat might be, however, that you have a standard weekly, monthly, or whatever meeting that you want to track charges separately. In such a case, you would create a separate work package and build in hours into that work package and those employees who participate in that package would charge it separately than perhaps their main charge codes. But as you can see it is a business choice based on how you wish to account for your dollars. My practice typically is to separate those supporting type tasks that are more general and constant in nature while having other supporting tasks that are more directly related to an account or work package to simply fall into the overall work of that account / package. Otherwise, the codes become onerous and hard to manage.