Main two problems with decision making in R&D

In my more than 20 years of experience in the software development industry, I found out 2 main problems with decision making:

• Rushing to make a decision even if it would destroy more than create.
• Delaying a decision thus hurting business agility and the value R&D should provide to the stakeholders.

A bit of explanation on my viewpoint:

R&D is there to research and develop software which would bring business value to the company, right? What does it mean? It means that a company needs to provide value to its customers to bring back money, thus making the company expand and become better solvent and more profitable.

For an organizational unit 'provide value' means - being helpful within the organization and bring about the desired product to its internal customers, so that it is worthwhile to keep and invest into.

Who decides if any effort is worthwhile for the business? Clients! For company - these are those who pay for its products and for an organizational units these are people who either make the requests for services or products or are in power to decide if the unit would live or die (higher management / owners).

In any case, it's clear that any decision should take into account the needs of the clients and the speed plus quality with which the product requirements are anticipated to be fulfilled by the decision.

Here comes the art of compromises, the depth of knowledge and the life of experience.

In agile world, there is a great way to verify a decision and it's: what's the business value that it provides divided by the possibly correctly estimated effort it would cost.

If value is too low or effort is too high - the decision is not good. Simplistic but workable!

So first problem - rushing with decisions - in most cases comes from not really understanding the efforts and not being fully aware of the requirements. Of course, it can also be the result of a truly professional deep knowledge of the existing product, software and also business requirements. But that is rare. Mostly some people tend to shoot before looking :)

The second problem - procrastination with the decision - is due both to lack of understanding of the business value a decision would provide, together with lack of ability to correctly evaluate the effort required for the implementation of any decision. From not knowing comes fear and worry.

Again, in the agile world, you take business value from the person or a small group of people who are intimately aware of the end clients needs and the money or other exchange they would give when the capability is delivered. Those are usually product owners, product managers, commercial directors or internally - experienced managers who are deeply aware of what is required from an organizational unit by its customers and why.

And in the agile world the effort estimations are given by the people who are as much knowledgeable in the existing design and code base as possible to realistically estimate the gap between what is and what is desired. Here the "what is desired" maybe outside of these people's knowledge and experience and might require input from consultants of other knowledge holders. Ok, so it should be combined!

Then, by correctly prioritizing the business value divided by effort needed, both as realistic as possible, a decision can be correctly made toward the best ratio: most business value with least effort.

This requires as small as possible amount of internal politics and as much as possible of internal communication together with organization wide sharing of knowledge and expertise, so correct people are consulted and correct conclusions are drawn.

To your success,

Alexander Stern
Software Architect and Lead Developer
Effective R&D Evangelist