Delivery Model

Let's start by first discussing some of the common delivery models for organizing your teams. A delivery model is simply a suggested configuration for a no-code team structure designed to support different levels of complexity and scale when building no-code applications. We will introduce three distinct delivery models in this section. Note, the process of actually picking which delivery model is right for your application should be guided by the Application Matrix.

The simplest delivery model is what we'll refer to as the "Do-It-Yourself" approach, where all the primary roles of the no-code project are contained within a team sitting inside a single business unit. This team typically has a single overall project sponsor overseeing them. This makes the business function highly autonomous and in charge of its own destiny as they do not depend on groups in IT or other organizations to form and execute a no-code project. There may be just a single no-code team. There may also be multiple teams in organizations that have a high level of no-code maturity and are building no-code apps for a large number of business units. The size of the team is less important than where the participants come from. In this model, all the roles should come from the same functional business unit that sponsors the app.

Considerations

• This is the simplest model for organization and execution, leading to efficiency and streamlined operations.

• Team roles may be easier to resource and operationalize by the business function because of reduced dependencies.

• Offers a clear definition of accountability and priorities within a single organization unit.

• May be constrained by the availability of skills and people in that group.

• Not having access to more technical development skills may lead to roadblocks.

• It will be challenging to embed a new no-code application into a legacy ecosystem without proper technical skills.

The next delivery model we'll introduce is that of a "Fusion team." This delivery model represents a multidisciplinary team with members coming from the business function and IT to collaborate. Typically, this model is used when you have greater technical requirements and complexity that require software developers to build some components of the no-code application. The software developers may still sit somewhere within the business function — perhaps a business function unit IT group — or they may be part of a centralized corporate IT function. They may also be tapped to provide expertise in specific technical areas, such as security or DevOps. Regardless of where they sit within the organization, there is shared accountability for the no-code app being built.

The fusion team model usually results in a matrix organizational model. Most of the key roles will still be driven by the business unit, but some specialized no-code roles may sit within an IT group. However, typically even any software developers who may be supporting the project from IT will have a dotted-line reporting relationship to the overall business unit.

Considerations

• Provides access to more technical development skills required by certain projects.

• Blends technology skills, analytical skills, and business domain expertise.

• Offers shared accountability for the no-code solutions being built.

• Offers higher complexity of governance because there will be a matrix of shared accountability across both the business unit and fusion team.

• Requires additional budgeting by the organization to fund more technical talent from IT.

• Slower and more resource dependent; requires more time to align IT and business functions.

The final delivery model is the "Center of Excellence," or CoE. The CoE is typically owned and led by a single overall cross-functional CoE leader. It has skilled knowledge workers whose mission is to maximize efficiency through consistent definition and adoption of best practices for no-code development across the organization. This approach typically does not get formed immediately but emerges after the organization has started building some no-code expertise from multiple projects. It then becomes attractive to standardize and centralize some no-code expertise and skills to leverage across teams. When this happens, it's often part of an overall digital transformation initiative. As the CoE is formed, it may or may not have direct full-time staff. Sometimes, the CoE lead can have direct employees working under its supervision or they can operate in a matrix environment working with no-code creators from other business units.

Resourcing a no-code project using the CoE model results in a matrix organizational model. Most of the key roles will still be driven by the business unit, but some specialized no-code roles may sit within the CoE. However, even the CoE resources will typically have a dotted-line reporting relationship with the overall business unit owner as a part of the development project.

Considerations

• Makes most efficient use of scarce resources across the organization by providing team members on a centralized and shared basis.

• Accelerates learning and adoption of best no-code practices across projects.

• Fosters a higher degree of no-code components reuse across teams within the organization.

• Offers higher complexity of governance because there will be a matrix of shared accountability across both the business unit and CoE.

• Requires additional budgeting by the organization to fund the centralized team.