Stage 4
Project Assignment

Despite constant evolution and innovation, custom application development projects can still be risky and may fail to meet the expectations of the business function. While there are many reasons for this, it’s well understood that longer and larger projects present higher risks including scope creep, budget/schedule overruns and, in the end — missed business opportunities. Trying to be overly ambitious and taking on too broad of scope when building software is a recipe for disaster! So, while the earlier stages of the No-code Lifecycle looked broadly at the business vision and requirements, and prototyped a broad view of the overall solution, this stage will now narrow our focus. Here, you’ll get a clear view of the achievable “target” that you want to aim for in the first release.

The Project Assignment stage defines the target scope of your no-code app that you will be building in the next phase (the Go-Live Phase). At a high level, it includes the following activities:

• Decomposing the business use case into smaller use cases.

• Selecting and confirming which of these use cases will be included in the initial Go-Live scope.

• Ensuring that the scope aligns with any timeline constraints established by the business function.

• Defining the necessary roles and participants in the project (using the delivery model suggested by the Application Matrix described in Chapter 5).

• Preparation for enablement of the release (including identification of power users, scheduling of governance checks, planning enablement, selecting the right set of environments, etc.).

We’ll be exploring each of these activities briefly in this chapter but, first, let’s start by digging into the concept of a “Minimum Viable Product” (introduced in Chapter 6).

In software development, the approach of defining a narrow initial release is often referred to as selecting an MVP. It is a concept taken from the book “Lean Startup” by Eric Ries. The approach stresses the benefits of defining the smallest scope possible for an initial software release. This approach allows you to quickly get the software in front of actual users to begin learning how they use the product and validate its business value. MVP emphasizes time to market over striving for perfection. It allows you to change direction before too much investment has been sunk into the current approach. By taking this iterative approach to development, you can use early feedback from real users to continuously enhance your software rather than investing time into building something your users don’t really want.

The MVP approach has some pitfalls. Some development teams may overemphasize the “minimum” in their scope and release versions that fail to deliver business value due to their limitations. When adopting MVPs, it’s critical that your scope definitions deliver enough value to warrant the rollout to end users. Remember the adage, “you never get a second chance to make a first impression.” If your MVP lacks sufficient value or capabilities, users may not stick around long enough to wait for it to evolve into something better.

With that defined, let’s walk through some of the key steps to perform in the Project Assignment stage.

Step #1 Decomposing the business use case

You should start with the overall definition that you first outlined in the business use case stage. This probably already included some definitions of smaller subprocesses that enable a broader business vision. During the Design and Prototyping stage, you likely further decomposed the overall processes into smaller subprocesses, prototyped with the no-code tools. This list of subprocesses provides a candidate inventory that could be part of the MVP but, for now, they are too broad to include in the initial Go-Live release and will need further prioritization. For example, thinking back to our Territory Management solution, the MVP may include the ability to assign accounts and track key account data points, including associated contacts, as well as capabilities to execute core engagement cadences. Meanwhile, other features, such as integration with a data enrichment tool, more sophisticated workflows, and an advanced dashboard, can be delivered after the initial MVP release.

Step #2 Selecting and confirming Go-Live scope

You should work with the no-code stakeholder to prioritize your inventory of candidate subprocesses based on the business impact and value to users. The work you have performed during the Design and Prototyping stage will have helped educate and inform your business stakeholders about the benefits by visibly demonstrating the value that will be released with the no-code app. At this point, attempt to work with the no-code stakeholder to define how far down the prioritized list you must go to deliver sufficient initial business value. Typically, the MVP scope should include at least one end-to-end subprocess. The key will be to identify the smallest set of individual subprocesses/business tasks that, when implemented, cover the most important part of the business requirements.

Step #3 Applying timeline contraints

In traditional software development, the timeline is often estimated either by a bottom-up estimate of how long it will take (common with waterfall development) or as a predefined structure of the release cadence (common with Agile, which will start with some defined sprints/releases). However, this works only in cases where the development team can arbitrarily set its own timetable without having any influence or constraints imposed by the market or business. Alternatively, we recommend that it’s often better to start with understanding the business timetable — there is usually some defined timeline linked to the agreed success criteria as stated in the Business Use Case stage (e.g., having the app support the launch of a new product or service, or enabling the rollout of a process change). It is important to understand external drivers and factors that will influence scoping of process/use cases.

Based on the timeline constraints, revisit the candidate set of subprocesses you prioritized and selected in the prior step. If you cannot fit the desired scope into the timeline, it may require a further narrowing of the scope to fit within the calendar constraints.

Step #4 Identify the appropriate delivery model

Now that the target scope is mostly defined, you should select the correct delivery model using the Application Matrix framework presented earlier in Chapter 5. This is important as it will help define the types of resources the project needs: Can the business team deliver this app independently? Is more support needed from a fusion team, including software developers (to build more complex components), or from the No-code CoE if one exists? Selecting the delivery model is also the key to sizing up or down the remaining stages in the no-code methodology, as some stages (in particular the “governance checks” in Chapter 14) may need to be scaled depending on the complexity of your needs.

Step #5 Defining roles and participants

With the delivery model set, you should start identifying the roles you’ll need for your project. A few considerations to keep in mind:

1. Multiple roles can be played by a single individual, especially on very small projects. However, beware of having people wear too many hats. Also, the no-code stakeholder should be independent of the full-time members on the development team because it’s important to have a sufficiently senior stakeholder who isn’t biased by the day-to-day tactical efforts.

2. Roles can be played by part-time members assigned to the project, but make sure that all individuals assigned to the project are able to spend a sufficient amount of time with the no-code team.

3. At times, it may be difficult to get sufficient resources assigned with the correct amount of bandwidth — especially resources from the business function, which typically already has full-time accountabilities to the organization in other areas. Ultimately, it’s the no-code stakeholder’s responsibility to make the case to management for freeing up the necessary resources to make the no-code project a priority.

Step #6 Future project enablement

Besides the individuals involved in the development effort, what other resources are needed to enable your project? This may typically include, but is not limited to the following:

1. Power users.
   While you may have some users already integrated into your no-code development team, you should plan to identify and recruit a set of “power users” (those who are highly proficient with the current business function/process and represent individuals who would give you more advanced and richer feedback). It’s important to have these power users test the app prior to going live, typically as part of a user acceptance test (which will be discussed in Chapter 15).

2. Governance checks.
   Governance checks. In a similar fashion, it’s recommended to identify and allocate resources of the governance team to test all the compliance and regulatory requirements; this won’t be performed until the Governance Checks stage (described in Chapter 14), but you’ll want to secure their time in advance proactively. Keep in mind that the types and depth of governance checks vary based on your application complexity, so use the Application Matrix to select and scale as needed.

3. User enablement planning.
   It’s also a good idea to start proactively building the user enablement plan so it’s not left to the last minute. It’s important to build the enablement content and schedule training and walk-throughs for application users. Too often, this is compressed late in the project as an afterthought. Start by assigning someone early in the project to own building the plan. They will work alongside the no-code development team as the app is built.

4. No-code environments.
   There will need to be some set of no-code cloud environments to support the development effort. There are typically at least two environments — development (where the daily core no-code building and testing take place) and production (where the “live” application will exist). This list will vary somewhat, and you may decide to add or remove environments depending on the complexity of the app and the number and size of teams. For example, more complex enterprise deployments may add additional quality assurance (QA) environments for more comprehensive testing efforts and often a preproduction environment (a close mirror to production, typically used for a user acceptance test). The Application Matrix can help you with the approximate sizing of environments.

5. Release strategy.
   Finally, after all of your team members have been assigned to these tasks, you can begin defining a roadmap and schedule for both MVP and subsequent releases. Identification of parallel vs. sequential delivery is another important step. Seek opportunities to deliver multiple apps and/or components in parallel.