In general, everybody thinks it is a simple topic. You pay, and you get results as expected. I will be honest! It is more complex than you ever imagined!

For a start, it is simple:

Output = (Time) * (Resource)

We can break resources into more details to catch the details:

Output = (Time) * (Cost * ((Field Knowledge factor - FKF) * (number of resource - NoR)))

The critical fact about field knowledge level and cost of the field knowledge: The cost goes on a linear path, while the Field knowledge factor goes exponential; with more knowledge, you can simply solve more complex problems.

To make the equitation more complex:

Output = (Time) * ((Business vision clearness - BVC / Business requirement documentation - BRD) * Cost * ((FKF) * (NoR)))

To make it more straightforward:

To successfully deliver, we also need some testing:

Testing factors have a number that is a factor in developments to correct the problem we

face. Later we face a problem; we will spend more to resolve it.

Subsequent addition is the maintainability:

With less abstraction and reusability, we use, we will spend more on maintenance. Writing

complex functions also increases the cost of maintenance over time. In an ideal case, it is a

number with one value. Over maintenance issues, the number decreases to a larger number

then zero but is small enough to consume most of the resources if we need to touch the

code.

The following piece of the picture is the talent retaining:

If we retain talents, we can give a complete performance, so the factor is one. Otherwise,

we spend time searching and interviewing talents, then hoping at the end of the learning

curve we still have them.

So, the final picture we have:

Let’s spend some time understanding what we have:

It is a basic assumption that we don’t want to release the basic quality requirements. We

want to provide quality service with reliable solutions!

If we have time, we can use fewer resources; if we don’t want to spend on the resource, we

must have time to have the expected results.

FKF – Field Knowledge Factor:

For skilled resources, we must pay more, but not as they provide an understanding of

complex problems. With more skills these people have, they will gather more productivity,

as they can create more maintainable code with more abstraction, what may a lower

performer doesn’t even understand. Typically, this is the difference between those codes

developed by highly skilled professionals compared to junior developers.

So, they not only increase the delivery capabilities but, in parallel, they maintain a high value

M – Maintainability

The cost will increase but not as much as these two factors. So even if we decrease the NoR

– Number of resources, we will have better overall output. The only constraint is time what

can hardly affect the output with this.

The testing (TF) is also connected to People! More complex situations, they prepare for the

test, we will earlier find problems – The problem resolution will take less resource and time!

It is valid for the BRD – Business Requirement Documentation, which belongs to an IT

Business Analyst role. With a Senior IT Business Analyst, we have fewer iterations until we

reach the required functionality. They both ask more questions to identify the business

requirements correctly and negotiate with the business to prioritize those items where we

can create the most value!

The equation works with internal developments where we ensure the entire supply chain is

controlled by us.

We can have alternatives on this math – We outsource the talents to a company!

First check the easiest one where we have external developers from a developer company.

They provide and replace the resources to ensure we continuously has the resource, they

provide resource we require for the time we require in number what required for delivery:

In typical case we simplify the case we expect the company has enough resources; they not

only hire when they see business.

As we don’t know the quality, we have two risk factors; if they do not assign the entire time

to the same developers, the code quality can vary and create inconsistency. This results in a

lower M factor, so we must provide more resources for the company to maintain its code.

If we see it from a commercial perspective, it is the ideal case; with a lower M factor, we

spend more on their developers to maintain the code.

This way, we created an additional risk to our equation where we have less control.

We can also outsource the testing where the Testing Factor will be affected. We get a code,

and we don’t necessarily see the test results. We will face this in the deployment. On the

one hand, we spend on our testing efforts, or we face the issue in the production

environment where we will spend most on the problem resolution!

If we use SaaS services or software from vendors, we don’t see these aspects. It is under sea

level. We see only the tip of the iceberg.

In short more parts we outsource of use externally, we create a risk factor of the unknown

where we can make bets, but we cannot be sure about the actual situation.

In my view, I like to control everything at the company level. We can use external resources

in addition to our resources, but never give the control out of our hands from strategy,

quality control (Maintainability and Testing, as it can cost us more on the long run)

Spending on quality people is worth the money, as their added value increases more than

the cost of their hiring.