We have now spent quite some time on the basics of agile project management – and this was also necessary so that the interrelationships of all subsequent content in this course become clear to us. But now we’ll jump right into the main topic, following the lifecycle of a requirement from start to finish.

Our first question is therefore: how do requirements arise in a company in the first place? And in our particular case, we ask specifically how requirements arise in a large company, because project management in large companies is quite different from the process in smaller companies or even a one-man show.

And with that, many project team members also experience the first big surprise. Please answer the question spontaneously: where do the requirements arise in a large company? Feel free to pause the video on this and give it some thought. I even suggest this to you quite explicitly.

Many would now say that requirements naturally arise among the employees who use software in the case of software development. Or with employees on a production line who operate the machines or assemble components there. These would be requirements that contribute to the optimization of work processes. In this way: I’ll put in a suggestion for improvement and it will be implemented at some point when capacity is free. And this is often also the claim that an employee associates with a suggestion for improvement.

In fact, however, requirements arise primarily from the top down, even extending beyond management. Requirements can be subdivided in many ways, e.g. into strategic, operational and regulatory requirements. Partners or shareholders are mainly interested in securing and increasing their invested capital. The largest shareholders of a company are usually represented on the Supervisory Board and supplemented by other Supervisory Board members with valuable experience and a network of contacts. In some types of company, of course, the employee side is also represented on the supervisory board. The Supervisory Board usually – but not necessarily exclusively – formulates strategic requirements. Examples of this would be necessary reactions to economic changes, reactions to the competitive environment, the expansion or concentration of areas of activity through acquisition or spin-off, technological developments, alliances and much more. The Board of Management or the Executive Board supplements the requirements of the Supervisory Board with further strategic and operational requirements. Operational requirements always aim to optimize business performance in the interests of shareholders and employees and therefore to respond to challenges in good time. Operational requirements also include regulatory requirements that originate from legislators in the countries in which the company operates. In addition, there are still sales-driven requirements for certifications.

The Executive Board collects the requirements of the Supervisory Board plus regulatory and operational requirements from its own sources and assigns these requirements to projects for implementation. And each project is given a budget and a time frame. A single requirement may justify a project, or multiple requirements may be realized in a single project. A project is then subdivided into several programs, e.g. in the area of human resources (in particular change management in the personnel area), the area of administration (for a necessary administrative reorganization), marketing, building management, production (for example, to purchase new equipment or machines), IT or even for our main area of software development. All these programs in sum should realize the given requirements in the project. And the programs in turn draw on one or more teams, depending on the complexity and organization of the company, to translate the increasingly granular requirements down into usable solutions. This is a very rough description of how requirements are created and implemented in solutions in a large company.

The implementation of a requirement through an employee’s suggestion for improvement thus presupposes that there is an ongoing project and thus also an available budget and free capacity for implementation. And this also explains why some suggestions for improvement seem to disappear into thin air.

So we can draw the following conclusion from this lesson: Requirements in a large company always arise from the top down. And with this insight, we structure this course from the emergence of a requirement, through the definition of a project, the formation of programs and creation of teams. We follow the workflow from start to finish.

Each company level has ceremonies, tools, roles and principles available for implementation from the fundamentals discussed in advance. But more about that in the following lesson. One small note: starting in this section, after selected lessons, you will find practice exercises where I describe a situation and you can develop a solution based on it using the project tools you have learned. As a preparation for your professional practice, I suggest you to do these exercises “before” the following solution lesson.