The key here is that in order for our production and development to behave predictably, we need to:

Select the components that are involved in the development-delivery-operation process. One example of such a component partition is shown in the picture.

For each of the components, determine how changes will be made to it, who is responsible for it, and how much responsibility to delegate to these people or scripts.

Make sure that if we have new components, for each of them we will make the same decisions.

I intentionally write "business processes / Value Streams", because. what exactly this will be is determined by us as a technical leader. These can be classic instructions in the form of a checklist or a BPMN diagram, in which case it is appropriate to speak of them as "business processes". These can be completely automated Software Defined Processes, and in this cSoftware development business processase we will most likely talk about them as a Value Stream. Often opposing DevOps and "classic IT" they mean the change of this particular paradigm - the replacement of "business processes" with "Value Stream".

If the concept is approved within the team, then the author of the concept presents it to the customer. According to the customer's comments, the concept is being finalized. When the contractor and the customer come to a consensus, the concept is fixed in the document version control system. The concept should be available to all project participants.

An analysis of the demand for the system should show whether this project is really interesting for the contractor, or whether it should be abandoned before too much money has been spent.

It would seem, why do we need an analysis of demand in the development of custom software? After all, the customer would not announce a competition if he did not need a program. However, the purpose of the demand analysis carried out by the contractor is to check how this project meets the interests of the business of the contractor itself.

Business interests are a very broad concept. In my practice, there were cases when we deliberately went for the implementation of a product that was not very profitable for us, but instead we got the opportunity to build trusting relationships with the customer and subsequently received orders that were beneficial for us. And, on the contrary, sometimes we refused to participate in the tender if it did not meet the interests of the business.

Sometimes I brought the customer's business process in the concept and showed on it the areas that our system was supposed to affect. In other cases, I indicated the old and new process schemes and showed how the new scheme was more effective than the old one and due to which our development provided better functional indicators.

If the customer is not afraid of UML diagrams, show him sequence diagrams: they very clearly demonstrate how different components of the system interact with each other. Activity diagrams can be provided. However, do not overdo it: diagrams in the concept are only needed to illustrate the principle of the program, nothing more.

Before accepting the concept as the basis of the project, it is necessary to review it. The purpose of such a review is to find out that the concept really meets the set goal and provides a solution to the set tasks, but at the same time is easy to understand and does not contain anything superfluous.

Since the concept is not written in technical language, it is customary for us to convene the entire project team, which is at that moment, to “defend” the concept, and even invite someone from outside. The author of the concept makes a short presentation, and then everyone present can ask their questions. The presence at the presentation of specialists from different fields and with different experience allows us to consider the proposed concept from different points of view. Sometimes the author goes to think further, more often he receives several very sensible comments.