COP — The Cost Oriented Planning Approach

If you hear someone talking about cost oriented planning for a software engineering solution, what would come to your mind in the first moment?

Well, if I had heard this four years ago, my very academic centered mind would immediately think about computacional cost, but it is not about computacional costs only that I am talking about here.

And I am saying only, because yes, even though computacional costs impact financial costs obviously, the use of the expression here is mainly based on financial costs planning while the engineering conception of a software solution in terms of resources availability and scalability.

And where has all this come from?

Recently in my actual job we made a spike to verify the engineering solution possibility of a business requirement and one of the points that guided me in the spike development process was financial costs.

Of course we had a problem to explore its possibilities, but costs in this specific case in my vision, were the point of scalability of the solution presented and without this the solution would become a problem in a short period of time requiring rethought which is related to spending teamwork time again in a new conception and implementation, costs that can be avoided, since time is money.

Thinking about nowadays solutions being planning, not considering financial costs in engineering resources sounds like having to do a brand new planning in a small space of time if the business demands an increase of access volume or even data storage, which occurs a lot in high increase companies.

It is in this sense that COP, the Cost Oriented Planning concept is approached here and yes, the chosen name and acronym are a funny relation with the well known OOP.

From now, if I don’t convince you yet to orient yours engineering solutions by costs, I will try to do this using a different approach, being more specific, a project management approach (and don’t, I don’t lose my mind, It will make sense, believe me).

When I was doing my MBA in project management I learned about how spending time planning a project (or a new feature, or product, or anything else…) saves money, because once we have everything detailed, the probability to finish the entire process without surprises can be real, or it should be at least.

The planning of a project can last months and once the process is finished, the manager and your team should have in hand the entire project planning to be executed. Several fields are analyzed and planned, but the core plan result fields are: escope, costs and time.

Well, in very poor words here, escope is the delimitation of the problem to be treated and when a feature or even a new product reaches finally the development team, normally the product team has already done the entire delimitation using methods like discoveries, turning this point more a product first concern than engineering one.

I will keep giving poor word explanations about the project management main disciplines, sorry about that, but this article should be feature/product centered, so I am trying to give you only enough concepts so you will be able to do the correlations with me.

So, the costs, a word that explains itself, here the manager and your team do all the costs calculations for the project. If we try to put this point in a feature/product engineering development domain we are thinking about resources, computational and human resources.

The computational resources can be any kind, use or not use cloud solutions, once already using cloud solutions, the different types of solutions available by the provider, besides the resources, the needed combination of them to build a well performed/high available/scalable approach whether the objective tends to this.

It is at this stage you should call Rihanna, because believe me, paraphrasing the singer: Bitch Better Have — The Money — !

Thank you, Riri, let’s back to the costs!

When we are planning a solution and split it on tasks with the product team, the planning can be a task itself, like the spike I mentioned before. The development of the planned ideia will be developed through tasks as well by the development team and during this period the whole developers worked hours will be relocated to here, so we have to plan very well this cost and this specific cost normally is addressed not in the planning of the solution, but in team rituals, like planning poker in SCRUMs teams for example.

Are you still here? It is almost there, I promise.

Think with me, if I have to rebuild my solution in a very short range of time, or in any acceptable range of time, I will spend again the capacity of my team on the same problem that is measured in time(!!) and this cost is being generated in this article by not planning well the computational resources that I chose, which takes us to the third and main field of project management planning, time!

Again, the name speaks by itself, the time is the amount of time spent in the whole project to achieve its objective (poor, very poor explanation). Here in the feature/product domain, this time is measured by the developer capacity as I said, that is a human resource, that is a cost as well!

When we have to turn ourselves again to a problem due costs that should be planned, we are losing time that could be spent on a new feature/product bringing even more value to the company.

In this sense, thinking about costs planning through this angle brings us to the understanding of why planning solutions by the cost perspective, because it is a problem that occurs, and that I have seen occur in fact, and that is not ok have to rethink once the solution is already in use, but this can be avoided, at least in many occasions.

I am not saying here however that plan the costs of your solution will eliminate the possibility of redo something about the developed strategy, because lot of unknown situations could happen, project management has a entire discipline for this topic as well, the management of risks, but it is not the point of today’s article, maybe another one (who knows?); but what I am really trying to say is: if you aggregate the COP concept in yours engineering solutions planning, this kind of rework can be mostly eliminated, since you know it exists and have conditions to think about it before it happens.