This post explores collaboration models for delivering projects in an agile manner within a regulated environment. This blog is based on a presentation given at ZHAW as part of the CAS in Agile IT Project Management program. Welcome.
“Regulated” means that a regulator imposes restrictions on a project’s process and technology and verifies—or has verified—compliance with those restrictions. Thus, it is not only the actual product itself that is regulated, but also the entire development process.
For example, the production of software for banks and insurance companies is not regulated. The local regulator does not monitor whether the software development process—and thus the project management of a software project—is compliant. Companies rely solely on their own internal specifications and guidelines. In contrast, the product—such as an insurance policy or an investment structure—is strictly regulated and must be approved and listed.
As a rule of thumb , the process is regulated wherever electricity flows. All electrical systems are subject to Functional Safety (IEC 61508). Even smartphones are regulated. However, not all components are. The operating system, for example, abstracts many aspects. Ordinary app developers do not have to worry about battery management and are therefore not regulated.
Another rule of thumb is that wherever people and lives are at risk, a regulator oversees the development process. This is self-explanatory for medical devices. Escalators and elevators, for example, are also regulated; in some countries, the regulations are even stricter, where skyscrapers line entire cities.
Non-regulated projects are organized using a project structure plan. This can be structured using a traditional or agile approach. A project structure plan corresponds to the planning dimension of a project. In our view, this is the most minimal structure required for a project. For a local counting app, a project structure plan is relatively straightforward and has at most two levels of abstraction. A complete elevator system, on the other hand, requires far more levels of abstraction, since complex systems consist of an electrical system with software and a mechanical system, both of which must be planned and structured accordingly. Certain regulations require an appropriate project structure plan, and standards also suggest templates. The main thing is to have something in place (evidence).
Depending on the industry and/or system, the regulator may require a specification dimension. This is usually derived from the generic V-model. It lists all artifacts as well as their relationships and traceability. This specification dimension is non-negotiable. A product-based risk analysis can provide a sound justification for local adaptation.
However, this specification dimension cannot be developed entirely upfront. That would be presumptuous and would not align with agile principles. The specification dimension emerges through typical Scrum sprints, is documented in the Definition of Done, and is part of built-in quality; see also our blog post “How Process Quality Reduces Costs.” Certain artifacts, such as the top-level system requirements, should, however, be outlined in advance; they guide the entire system development process. In any case, the regulator’s requirements must be taken into account, as the regulator often combines various artifacts into milestones and approves them.
Companies in some industries are organized on a project-oriented basis. They develop individual solutions that have nothing in common with one another. A single project can take years. These companies have trained project managers to translate customer requirements into technical requirements and to move from team to team. Such an organization is not to be dismissed; rather, it simply optimizes its operations in line with prevailing project development guidelines (or a project-based product development structure ).
Companies in other industries have stable teams, where projects, if anything, fund these very teams. Such an organization is not grouped by projects. It is stable teams that get the work done. This type of organization is also known in the industry as a product-oriented organization (or team-based product development organization ).
We provide models for both organizational patterns. However, models are just models. They must be adapted and fleshed out in workshops, particularly based on regulatory requirements. Likewise, our models are focused on product development organizations such as research and development. The models also do not address how the organizational structure is defined. They are purely process models.
We envision a kind of “building block system” for projects within the organization. These projects have an intensive “inception” phase. During this phase, the essentials for the project’s progress are established:
The process is similar to an Iteration 0. The focus is on establishing all necessary prerequisites to ensure that the team is operational and compliant with regulatory requirements.
Afterward, the project team operates in a continuous Scrum cycle. All activities necessary to develop a product increment that complies with regulatory requirements should be completed within a single sprint.
In a team-based product development organization, the organization is not grouped by projects or even products, but by teams. Employees are assigned to their teams. The teams take on the work.
These “stable teams” are balanced in terms of their skills and bring together all the disciplines necessary to develop a product increment. They operate in a classic Scrum mode.
To address regulatory complexity, five specialized teams support the stable teams.
This structure is suitable for product development organizations where multiple teams (must) work on products simultaneously.
All organizations that develop products for the market must take that market and its regulator into account. A well-designed Target Operating Model (TOM) for a product development organization is essential.