Project Assignment

This Toolkit for Project Assignment provides example checklists and questions to help you ‘hone-in’ on the specific scope for the important first release of your app. This requires you have decomposed the Business Use Case into smaller elements, selected and confirmed which ones are part of the initial Go-Live scope, and aligned around any specific timelines or important success criteria essential to the business. This also helps you select the right team and delivery model, assign resources, and initiate the project. Refer to the supporting material around both the key Roles and Responsibilities (Chapter 4), and Application Matrix (Chapter 5), which will be referenced throughout the guidance.

Keep in mind this first MVP release is merely a first step towards a longer-term vision defined by the Business Use Case. However, while the application in this stage will definitely evolve over time, in this stage it plays a critical role by delivering the first step along the longer-term roadmap and building momentum that will drive future user and business adoption.

The inputs from the prior stages will prepare for the Project Assignment activities. You should collect/update documentation organized around your business use case, workflows, and features.

• The Business Use Case articulates the problem, solution and success criteria over the overall initiative. This was first defined in the Business Use Case stage and additionally validated / refined during Prototyping & Design.

• Workflows (1:n per Business Use Case) outline the sequence of steps or actions a user would take to interact with the system or process, as well as the expected outcomes and business value of each. These also have been validated / refined during Prototyping and Design.

• Features (1:n per Workflow) are smaller, more focused sets of activities part of a larger workflow. They are a subset of the main process and typically designed to accomplish a specific task or sub-objective within the overall workflow.

• Working Prototype: The above definitions should be documented both in the form of a written inventory, but will also be delivered as part of the working prototype built in the last stage. However, keep in mind the Prototype may be complete or reflect ‘happy path’ requires, so the Prototype should not be the only input into formal estimation of the MVP.

Much of the focus of this stage will now be taking these concepts and what you have learned, and shaping this into the scope of the MVP release. The MVP release should be defined with as small a scope as humanly possible for the initial software release, so you can get the software quickly in front of actual users and begin learning about how they use the product and validate its business value. This approach emphasizes time to market over striving for perfection and allows you to change direction quickly before too much investment has been sunk into the current approach. It also allows you to learn from real users; then you can continuously enhance the software based on their feedback rather than building something your users don’t really want.

Defining an MVP scope can be challenging, as it requires balancing the minimum set of features needed to deliver value to users while also being feasible to develop within a reasonable time frame. You will need to shape MVP based around your specific requirements and business environment, but based upon our experience there are typically two general models to follow: an ‘End to end (E2E) Process’ or a ‘Complete Workflow’ approach. Both have distinct advantages and tradeoffs and will be explored in the following sections.

The E2E Process Approach defines the MVP around the ‘happy path’ of the full process to enable users to complete the main actions defined by the Business Use Case. This is best suited for processes that are fairly standard, with few deviations. If the standard process can be addressed sufficiently end-to-end, it can deliver the majority of the value identified in the original business use case, with the variations or ‘edge’ cases that are not addressed, but may be covered by an alternative solution (if such an exists), or even legacy or manual processing to cover missing functionality.

Let’s take an example of the retail lending flow for a Bank. If the majority of the loan applications can be pre-scored in an automated way (e.g. using credit history of the applicant, income analysis, collateral availability, etc.), and deviations from the standard flow are minimum (e.g. high-risk applications are less than 5% of the total), it’s likely more logical to design full business use case as an MVP as you can provide really fast automation for 95% of your business; while ‘edge’ cases can be still processed manually (and should be, as it requires the involvement of the Credit Committee, Risk Officer, etc.).

This E2E Process Approach has several advantages and challenges.

• Advantages:

  • Defining the ‘happy path’ of the full business use case as the MVP scope ensures that the essential functionality of the solution is working as intended, which can be critical for realizing the expected project benefits and delivering on the business case/OKRs.

  • The E2E process approach may have the shortest time to initial release as you can focus on implementing a single standard process and set of workflows without getting caught up in lots of edge cases that may represent highly complex features and require more implementation time.

  • This approach can enable overall high satisfaction by ensuring users can complete the primary or majority of the actions of the solution without encountering any significant issues. The most common and most frequently used steps in the process can be performed using a single automated digital solution.

• Challenges:

  • By only focusing on the ‘happy path,’ edge cases and exceptional scenarios may be overlooked. This can lead to a non-functional solution in these situations and cause frustration for users.

  • By not including less optimal scenarios in the MVP scope, the project team may miss out on valuable feedback from users on how the solution performs in those scenarios. This can result in a less polished and refined solution when released and affect post-MVP scope.

  • If the MVP scope is too rigidly defined based on the ‘happy path,’ it may be perceived as inflexible and unable to incorporate new features or changes that may be important as user feedback comes in. This can limit or slow the potential of the solution to evolve and improve.

  • By only considering the ‘happy path,’ the project team may not have a complete understanding of user needs and pain points. This can lead to the development of a solution that only partially meets user needs and does not provide a complete solution.

Using this approach, even though you may prioritize the ‘happy path’ when defining an MVP scope, it is also important to consider a range of scenarios to ensure the solution meets user needs in a variety of situations. Even if these scenarios are not built out during the MVP release, it is important to try and anticipate them so they can be accommodated into the application in as graceful a way as possible in future updates.

The ‘Complete Workflow’ approach defines the MVP around a focused but complete subset of the full business process, enabling users to perform a single workflow drawn from the Business Use Case. It is best suited for use when a targeted workflow (or subset of workflows), can deliver value by providing a complete and coherent user experience to end users. This can deliver a more compelling user experience, which can be an important driver for user adoption and retention.

Let’s illustrate this with another example based around a lending flow for legal entities. If the most important part of this lending process is to collect all existing information about the applicant to make a weighted decision for granting the loan, the decision-making process may be really complicated, and it might not be feasible to try and just address a simple happy path. In such case, it’s suggested to concentrate efforts on the most critical part of the Business Use Case – e.g. the Loan application - to ensure all next steps in the automated process (post-MVP improvements), are fulfilled with the necessary information about the borrower on the first step.

This Complete Workflow Approach has several advantages and challenges.

• Advantages:

  • Focusing on a specific workflow can help you deliver a more complete and fleshed-out user experience, improving adoption for a targeted set of users. By delivering all of the necessary features (including exception or variant logic), the need for a single function delivers a complete and productive experience that encourages frequency of use.

  • This approach may offer the highest expected business savings for digitizing a single workflow since you often can completely replace the current manual or legacy steps and replace it with a fully automated function.

  • This approach can offer the highest level of user satisfaction since it offers a coherent and streamlined experience where users can complete 100% of the steps that are part of a single business function.

• Challenges:

  • Focusing on only one workflow can limit the scope of the solution, making it less useful for a broader range of users. This can sometimes lead to more limited adoption and revenue potential.

  • Due to the additional complexity of fully meeting edge scenarios, this approach can take longer to develop and release, which can reduce or delay user feedback. This can make it difficult to make important incremental changes and updates to the solution based on real-world user feedback, potentially leading to missed opportunities for improvement.

  • A Complete Workflow approach often involves integrating multiple systems and components, which can increase the complexity of the solution. This can make it more difficult to develop, test, and maintain, potentially leading to delays and increased costs.

  • This approach can also involve a higher level of risk since it requires more extensive development and testing. This can lead to increased costs and delays if issues arise during development or after the solution is released.

Overall, while a ‘Complete Workflow’ approach can be valuable in some cases, focusing on only one workflow can take longer to implement and narrow some of the user adoption. It is important to consider the broader context and potential user base when defining an MVP scope to ensure the solution meets the needs of a wide range of users and provides value in multiple use cases.

In general, there is no ‘right answer’ to choosing the approach for shaping MVP. The best approach will depend on your specific Business Use Case and the goals you are trying to achieve with your MVP. If you have a specific feature that is critical for your project success, focusing on delivering a complete end-to-end experience for that workflow may be the best approach. If your success depends more on the core functionality working correctly, focusing on the ‘happy path’ through an E2E process may be the better option. Ultimately, the most important thing is to focus on delivering the most value to your users with the minimum set of features required to achieve your goals.

With the MVP defined, you’re now ready to start sizing and estimating the solution. This can be daunting especially if you do not yet have much experience drawn from prior no-code projects. Here’s how to begin the process with a simple no-code estimation framework.

Step #1: Confirm the level of complexity and assess project Delivery Model	If you have not already identified the appropriate Delivery Model, refer to (Chapter 5) around use of the Application Matrix and sizing the complexity of your project. Even if you have performed an initial Application Matrix assessment previously, you may still consider revisiting as the complexity may be different based upon now defining the target MVP scope. It's possible that a narrowly defined MVP may reduce some of your prior assumptions on complexity which may change the target Delivery Model.
Step #2: Ensure Workflows and Features are sufficiently decomposed.	During the definition of MVP, you should have reviewed the business process and workflows to ensure they are not too high-level, but are appropriately decomposed into the multiple sub-processes or sub-workflows that allows you to clearly define scope. Estimation will start after decomposing your Business use case into workflows and workflows into respective features (if this makes sense when Workflow is non-trivial). Decomposing workflows is highly recommended for Business Use Cases of CoE or Fusion team complexity.'hly complex or cross-functional process requirements)
Step #3: Establish / refine T-shirt Sizing team estimating guidance	‘T-shirt sizing’ is an approach whereby you estimate the effort of a feature by assigning a t-shirt size—from Small (S) to Extra Large (XL) (or sometimes from XS to XXL) —to represent that task’s relative effort. The benefit of T-shirt sizing is that it provides the entire team with an easy, clear understanding of relative feature sizes. This can be especially useful if the team is new to No-code, as T-shirt sizing is easy to understand and most team members can quickly grasp the relative differences (e.g. comparing a Small and a Large feature). These estimations usually are ideally based on the experience of your previous no-code projects. However, even if you don’t have much experience, don’t worry – we present below some rough estimating factors to get you started. You should fine tune this as you build experience, based upon your own team’s level of productivity or proficiency with No-code.
Step #4: Use Workflow and Feature inventory to perform T-shirt sizing” build estimations	You’re now ready to go thru the inventory of workflows and features (defined in your MVP release), and begin to apply the t-shirt sizing guidance to produce the build effort. For each feature, you should break out and consider complexity related to various criteria - e.g. Data Model, UI, Business logic, Integrations, Access rights, Reports, Mobile, and Customer\Partner Portal (not all may apply).
Step #5: Add additional effort to the overall total to reflect other project activites	Estimation is not just equal to the sum of its feature build estimations, and you will need to plan for time to reflect additional activities that may need to be performed into the project. Quality assurance/testing effort — as a rule of thumb, roughly 1/3 of build effort goes into validation and verification of the functionality. Project management and governance effort — this depends on the chosen methodology and maturity of the team but typically takes around 10-20% of the total effort of the project. Initial data import (if applicable). This effort depends on the quantity of entities to migrate (e.g., lead, case, account, contact) and data volume (quantity of records per entity, e.g., 1 million contacts, 3 million cases) Non-functional requirements (if applicable) — you may need to add in specific efforts related to meeting non-functional requirements as part of the project effort, such as performance/scalability testing, capacity planning, reliability, availability testing, etc. Governance and compliance (if applicable) — you should plan to add in the specific effort related to security and compliance checks. These can vary widely and will be covered in more detail in the chapter on Governance Checks (Stage 7). End-user training effort (if applicable) — you may need to add a specific effort related to end-user training or enablement support. This can vary widely depending on the number, location, and languages spoken by users. Location effort (if applicable) – if the app will be used by users in multiple languages, this may require localization time.
Step #6: Use the Application Matrix to refine estimates	The Application Matrix can do more than simply select the delivery model and roles for your project. It can also be used to help scale-up the effort estimate as well. For example, applications with ‘advanced’ levels of business complexity and technical complexity will likely require more time and effort for the development effort. One way to reflect this is to apply a ‘complexity multiplier’ on top of the bottom-up estimate to provide additional room in the estimate for the greater complexity of the no-code application. A complexity multiplier will vary widely based upon your team’s knowledge of the business domain, their no-code experience, and your targeted industry and processes. Therefore, it’s difficult to provide an absolute rubric for this – but it would not be uncommon to apply a multiplier of 1.2 to 1.5x or more to allow for the greater uncertainty and complexity of advanced complexity applications. A greater complexity multiplier may be required if venturing into an entirely new process or domain where there is high uncertainty. It is highly recommended however to try and address this with exploratory prototyping to help reduce uncertainty, before committing to a final estimate – you don’t want the estimate to be too high or too low. Prototyping helps you explore and refine this without committing a large amount of effort. The use of a complexity multiplier should be applied carefully by a No-code Architect as part of the estimation process, based upon their experience in working with the team over a number of development cycles. This will allow the refinement based upon a history of development.
Step #7: Define the project schedule / resource plan	Completion of the estimate will give you an ability to build a high-level timeline for the MVP delivery and assign all needed resources, considering the complexity of each separate feature in the scope. While in practice, productivity vary based on the level of expertise of individual resources on the team, it is suggested you start by using average factors for No-code Creators of the same background (especially if they have certification passed on the platform). This allows T-shirt sizing to be converted in the time needed.

So, to put this into action, let’s provide an example of applying this estimation process, using the Credit Union Loan application scenario referenced earlier. In this scenario, we are using no-code to build a loan application app for a Credit Union who allows members to apply for loans online and then automate the loan application process using a new digitized workflow approach. We have chosen the ‘complete workflow’ MVP approach and will be focusing on just the workflow for capturing the online application – this allows borrowers to fill out a loan application form online, providing their personal and financial information. Once submitted, the app also allows for streamlined tracking and review of the loan applications (by Underwriters and members of the Credit Committee), and allows them to either be approved or rejected as part of the workflow.

Step #1: Confirm the Level of Complexity and Assess Project Delivery Model

In this example, the level of business process complexity is fairly low – the new no-code app is merely a streamlined submission form (replacing a paper form), that automates collection and review of applicant information. The complexity of the process is not in the form itself, but is embedded in manual processes or other existing backend systems. Using the Application Matrix, we identify that the appropriate Delivery Model for this initial MVP is a ‘DIY Team’ model.

Post MVP, we will start to introduce integration with some of the legacy backend systems. (e.g. loan origination, credit scoring, loan servicing, payment processing, KYC and Fraud management, compliance, etc), Given the number and higher degree of technical complexity of the integrations, the appropriate Delivery Model in later updates may require a ‘Fusion Team’ model, as additional developer and security/compliance skills will be needed as part of the project team. Also, given the sensitivity and compliance requirements of the customer financial data, the Governance complexity would most likely be considered high.

Step #2: Ensure Workflows and Features are Sufficiently Decomposed

For defining the MVP, we will focus on just the loan application digital form capture and workflow This is straightforward and can be delivered rapidly. The integration into the various backend systems (e.g. loan origination, credit scoring, loan servicing, payment processing, KYC and Fraud management, compliance, etc), will introduce a higher degree of technical complexity, however we will introduce those features into a later update post MVP.

For simplicity, we will merely select two feature examples of the MVP.

Feature

As Underwriter, I want the possibility to approve and reject loan applications (with comments)

As Head of Credit Committee, I need to see lists of applications sorted by approval status

These two features were decomposed out of the loan application review workflow.

Step #3: Establish / refine T-shirt Sizing team estimating guidance

Here’s an example of T-shirt guidance that the team started, based around general no-code feature T-shirt estimating factors.

Size	Explanation	Time Unit	Suggested Time
S	Basic no-code customization (e.g., adding fields)	Hour(s)	4-8 hours
M	Complex no-code customization (e.g., business process with many branches and conditions)	Day(s)	8-40 hours (varies based upon team experience & workflow complexity; should be < 1 week)
L	The low-code effort required (e.g., adding basic JavaScript rules to UI)	Week(s)	40-80 hours (varies based upon team experience & complexity; should not be > 2 weeks)
XL	Complex coding is required (e.g., adding a new telephony integration feature to the telephony connector)	Varies; suggested to further decompose	TBD (varies based upon pro dev complexity, development approach, etc.).

The no-code team used standard estimating factors to get started, but over time as it builds more experience, these will be fine-tuned and adjusted based upon the team’s level of productivity or proficiency with No-code.

Step #4: Use Workflow and Feature Inventory to Perform ‘T-shirt sizing’ Build Estimations

Taking the feature subset identified earlier (as part of the MVP scope), we will now begin to estimate the feature build effort by applying the estimating factors.

Note these features by themselves are mostly automating paper forms and human review processes, and as a result are sized as relatively small t-shirt sizes. However, as noted before, once the form is submitted to backend systems, there will be increased complexity due to the backend integrations. Those features likely would show L or XL effort, depending upon the degree of openness of their APIs or whether pre-built integrations might exist from a third party source like the Marketplace.

Based upon the defined feature t-shirt sizes, and the baseline estimating guidance, let’s prepare the build estimate for the two features.

• Approval of the loan = M+M+M+S+S

• List of applications = S+S+S+S+S+S

Based on the team experience, S = 4 hours, and M = 2 days (16h)

Total build estimation for 2 features = 80 hours

Step #5: Add Additional Effort to the Overall Total to Reflect Other Project Activities

In addition to the build effort, we will add in time to account for User Acceptance Testing and overall project management effort. Given the relatively small effort and short project duration, we need to be careful not to overwhelm this initial MVP with too much testing and management burden.

Likewise, as this simply replaces existing paper forms and processes, it does not introduce any new regulatory or compliance considerations; so, for the purposes of this MVP, we are not accounting for conducting any new compliance checks.

Step #6: Define the Project Schedule / Resource Plan

This means the time needed to develop the solution: 80 hours/ 2 FTE/40 hours/week = 1 week.

This is depicted as the following timeline:

So, for the purposes of planning and scheduling, the project can be delivered within 2 weeks to production. This assumes the No-code platform environment is already provisioned, and the deployment of features has been fully automated.

After a couple iterations of MVP development, the team will quickly start to gain a better understanding that will allow you to re-estimate or refine your assumptions with this understanding.

Industry/Process knowledge on the team can have a strong impact on estimates and overall productivity. The degree of subject matter knowledge around the industry or process will result in a multiplier on build velocity, and also reducing the number of iterations to build and polish.

More T-shirt sizing tips:

• Usually, we recommend that it is better at this stage to estimate t-shirt sizes using a bottom-up approach — i.e., starting from features and summing up to produce an estimate for the workflow and process, and eventually the Business Use Case overall.

• Make sure the team is aligned on what each t-shirt size means. This may seem obvious, but T-shirt sizing only works if everyone understands what each size represents. So, as you introduce this estimation practice to your team, ensure everyone is on the same page about it. Provide common examples of a Small vs. Large project.

• Clarify what a t-shirt size represents. Does the size represent effort? Complexity? Time? Often, a t-shirt size represents all of the above, but clarifying what you are (and are not), tracking with t-shirt sizes is a helpful way to get everyone on the same page.

• Depending on your team structure, define who should be the primary resource that assigns t-shirt sizes or opens it up for the entire team. Here are a few common ways to assign t-shirt sizes:

  • The Business Architect often plays a lead role in t-shirt sizing; for some smaller projects, they may perform all estimation.

  • For larger No-code project teams, each No-code team member may be responsible for setting their own t-shirt sizes based on the team’s understanding of what each size of work represents.

  • For features related to specific business processes, the team may identify a process SME that assigns t-shirt sizes because they’re closest to the understanding of the process.

  • For teams who are part of a CoE Delivery Model, the CoE Business Architect often reviews t-shirt sizes, which were previously assigned by the No-code team, before starting the work.

  • For teams that are part of a Fusion Team Delivery Model, an IT developer or architect may perform the estimation related to custom software components. As these features may be built using Scrum or other development methodologies, they should be estimated and planned accordingly.

More Sheduling Tips

After you estimate the effort bottom up and produce a draft schedule based on resources, you should also consider some ‘top-down’ validation of the schedule to assess if your timelines are delivering value fast enough to your users and stakeholders. This may require you to look at adding additional resources in order to achieve the desired level of velocity.

• As a very general rule of thumb, we would commonly expect to see MVP delivery of the following timelines for each type of delivery model, assuming the right level of resourcing.

  • DIY projects: 1-2 weeks (including both build + UAT + deployment)

  • CoE projects: 2-4 weeks (including both build + UAT + deployment).

  • Fusion projects: varies based upon development, but should < 2 months

• Delivery schedules will, of course, vary based on your requirements and target scope. However, if the timelines are significantly longer than the above-suggested ranges, it may be that either the MVP is still too broadly scoped and needs to be further decomposed, or you may want to consider adding more resources if available.

• Regardless of the delivery model, there are a number of factors that will impact the schedule. Some of the typical major variability drivers of the schedule include:

  • Complexity/variations of workflows — more complex processes may require numerous iterations to address all edge scenarios or variants. This is especially true with the ‘complete workflow’ approach to MVP.

  • Existing team knowledge of industry/process — as stated above, the team's knowledge can significantly impact. This is true not just for effort but also for scheduling, as familiarity and knowledge of the industry/process domain can greatly shorten the number of iterations to finish and polish the app.

  • Number and complexity of integrations — the same is true regarding integrations. Complex integrations to backend systems — especially if they require custom development of interfaces — will usually lengthen the schedule as both build and testing will go through multiple iterations during delivery and also UAT.

  • Complexity of UX — apps with more complex user experiences (e.g., mobile, customer/partner portal, reports/analytics, etc.), can also require longer schedules. This can be driven by the need for greater testing across a broader range of devices and getting broader types of user feedback during feedback and testing, which requires more polishing.

  • Complexity of Governance and compliance — another important schedule consideration is related to security and compliance checks. These can often be overlooked and lead to last-minute delays that block the project from going live. This topic will be covered in more detail in the chapter on Governance Checks (Chapter 14).