How to Estimate your Appian Projects

Appian Max Team — Thu, 05 Sep 2024 18:42:47 GMT

Current Revision posted to Guide by Appian Max Team on 9/5/2024 6:42:47 PM

Skills Covered

Accurate project and resource requirements estimation is the cornerstone of any successful Appian project. However, accurate estimation isn't always easy: understanding which factors drive resourcing requirements and how is key to successful estimation.

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

The approach helps inform project control parameters - cost, time, and resources, during the proposal phase. This approach aligns with Agile delivery methodologies which acknowledge that requirements will change and solution development is an empirical process.

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

The Estimation Session should be composed of experienced Appian practitioners. A diversity of Appian delivery experience drives better estimates. Indicative examples of project estimates are provided below.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

Note that new versions of Appian (released quarterly) may contain features that reduce or even remove the complexity impact of a factor. See the latest Appian Product Documentation to keep up on new features.

1) Records

A Record is data that represents a central business concept. "Employee", "Vehicle", "Account" are all examples. Records provide a centralized view of a given business function, along with all of its connections to related records.

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Highly complex workflows require extensive testing to ensure all pathways function as designed.
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

User Interfaces are pages composed of/configured from various components in the Appian UI components catalog and are the elements of the solution that end-users interact with directly. User Interfaces must be intuitive and compelling to use.

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

These characteristics could increase the effort required to design, build, test and deploy reports

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Delivery Methodology - Agile delivery methodologies are particularly well suited for low-code application development. Other methodologies, such as waterfall, can be utilized successfully, but fail to capitalize on many advantages of the Appian low-code platform, ie. functionally complete and feature rich short build iterations, low cost of change, inherent robustness and fast time to production usage. If non-agile methodologies are utilized to deliver Appian projects, it might be prudent to account for longer delivery timelines for equivalent functionality.

Self-managed vs. Appian cloud - Self-managed installs of any tool introduces dependence on different internal teams for infrastructure, networking and maintenance. Appian cloud takes away most of these dependencies thereby reducing risk and potentially longer engagements.

Regulatory Requirements - All parts of a solution meeting regulatory requirements must usually adhere explicitly to the guidelines. This often requires additional functional and performance testing. Not all regulatory requirements negatively impact project size and complexity. Therefore an understanding of the requirements, how they affect architecture, design and testing is important to correctly judge the effect on the estimate.

IT Requirements - These are non-Appian platform specific requirements such as additional documentation needs, specific gate criteria for quality, specific deployment requirements etc. could have an impact on the overall size of the project. These must be understood and planned for.

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management, Project Estimation, Vision

How to Estimate your Appian Projects

joel.larin — Tue, 03 Sep 2024 15:48:51 GMT

Revision 53 posted to Guide by joel.larin on 9/3/2024 3:48:51 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Highly complex workflows require extensive testing to ensure all pathways function as designed.
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

These characteristics could increase the effort required to design, build, test and deploy reports

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management, Project Estimation, Vision

How to Estimate your Appian Projects

joel.larin — Tue, 03 Sep 2024 15:48:28 GMT

Revision 52 posted to Guide by joel.larin on 9/3/2024 3:48:28 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Highly complex workflows require extensive testing to ensure all pathways function as designed.
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

These characteristics could increase the effort required to design, build, test and deploy reports

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management, Project Estimation, Vision

How to Estimate your Appian Projects

joel.larin — Tue, 03 Sep 2024 15:47:53 GMT

Revision 51 posted to Guide by joel.larin on 9/3/2024 3:47:53 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Highly complex workflows require extensive testing to ensure all pathways function as designed.
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

These characteristics could increase the effort required to design, build, test and deploy reports

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management, Project Estimation, Vision

How to Estimate your Appian Projects

joel.larin — Tue, 03 Sep 2024 15:46:35 GMT

Revision 50 posted to Guide by joel.larin on 9/3/2024 3:46:35 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Highly complex workflows require extensive testing to ensure all pathways function as designed.
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

These characteristics could increase the effort required to design, build, test and deploy reports

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management, Project Estimation, Vision

How to Estimate your Appian Projects

joel.larin — Tue, 03 Sep 2024 15:45:52 GMT

Revision 49 posted to Guide by joel.larin on 9/3/2024 3:45:52 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Highly complex workflows require extensive testing to ensure all pathways function as designed.
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

These characteristics could increase the effort required to design, build, test and deploy reports

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management, Project Estimation, Vision

How to Estimate your Appian Projects

joel.larin — Tue, 03 Sep 2024 15:40:39 GMT

Revision 48 posted to Guide by joel.larin on 9/3/2024 3:40:39 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Highly complex workflows require extensive testing to ensure all pathways function as designed.
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

These characteristics could increase the effort required to design, build, test and deploy reports

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management, Project Estimation, Vision

How to Estimate your Appian Projects

Appian Max Team — Tue, 23 Apr 2024 13:12:32 GMT

Revision 47 posted to Guide by Appian Max Team on 4/23/2024 1:12:32 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Highly complex workflows require extensive testing to ensure all pathways function as designed.
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

These characteristics could increase the effort required to design, build, test and deploy reports

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management, Project Estimation, Vision

How to Estimate your Appian Projects

joel.larin — Wed, 01 Nov 2023 13:51:22 GMT

Revision 46 posted to Guide by joel.larin on 11/1/2023 1:51:22 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Highly complex workflows require extensive testing to ensure all pathways function as designed.
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

These characteristics could increase the effort required to design, build, test and deploy reports

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management, Project Estimation, Vision

How to Estimate your Appian Projects

Appian Max Team — Thu, 05 Oct 2023 17:58:08 GMT

Revision 45 posted to Guide by Appian Max Team on 10/5/2023 5:58:08 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Highly complex workflows require extensive testing to ensure all pathways function as designed.
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

These characteristics could increase the effort required to design, build, test and deploy reports

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management, Project Estimation, Vision

How to Estimate your Appian Projects

joel.larin — Tue, 18 Apr 2023 18:25:51 GMT

Revision 44 posted to Guide by joel.larin on 4/18/2023 6:25:51 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Highly complex workflows require extensive testing to ensure all pathways function as designed.
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

These characteristics could increase the effort required to design, build, test and deploy reports

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management, Project Estimation, Vision

How to Estimate your Appian Projects

Devon Lee — Wed, 22 Mar 2023 16:11:01 GMT

Revision 43 posted to Guide by Devon Lee on 3/22/2023 4:11:01 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Highly complex workflows require extensive testing to ensure all pathways function as designed.
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

These characteristics could increase the effort required to design, build, test and deploy reports

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management

How to Estimate your Appian Projects

joel.larin — Wed, 01 Mar 2023 20:12:35 GMT

Revision 42 posted to Guide by joel.larin on 3/1/2023 8:12:35 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Highly complex workflows require extensive testing to ensure all pathways function as designed.
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

These characteristics could increase the effort required to design, build, test and deploy reports

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management

How to Estimate your Appian Projects

joel.larin — Wed, 01 Mar 2023 20:09:51 GMT

Revision 41 posted to Guide by joel.larin on 3/1/2023 8:09:51 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Highly complex workflows require extensive testing to ensure all pathways function as designed.
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

These characteristics could increase the effort required to design, build, test and deploy reports

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

Appian Reports are a sub-category of User Interfaces that share these characteristics:

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management

How to Estimate your Appian Projects

joel.larin — Wed, 01 Mar 2023 20:07:11 GMT

Revision 40 posted to Guide by joel.larin on 3/1/2023 8:07:11 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Highly complex workflows require extensive testing to ensure all pathways function as designed.
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

Appian Reports are a sub-category of User Interfaces that share these characteristics:

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

Appian Reports are a sub-category of User Interfaces that share these characteristics:

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management

How to Estimate your Appian Projects

joel.larin — Wed, 01 Mar 2023 20:03:50 GMT

Revision 39 posted to Guide by joel.larin on 3/1/2023 8:03:50 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Complex validations, such as:
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

Appian Reports are a sub-category of User Interfaces that share these characteristics:

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

Appian Reports are a sub-category of User Interfaces that share these characteristics:

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management

How to Estimate your Appian Projects

joel.larin — Wed, 01 Mar 2023 19:54:06 GMT

Revision 38 posted to Guide by joel.larin on 3/1/2023 7:54:06 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Dynamic Risk Mitigation

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Delivery Governance Model

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Complex validations, such as:
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

Appian Reports are a sub-category of User Interfaces that share these characteristics:

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

Appian Reports are a sub-category of User Interfaces that share these characteristics:

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Dynamic Risk Mitigation

Indicative examples of project estimates are provided below.

Tags: Delivery, program management

How to Estimate your Appian Projects

joel.larin — Wed, 01 Mar 2023 19:52:57 GMT

Revision 37 posted to Guide by joel.larin on 3/1/2023 7:52:57 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Dynamic Risk Mitigation

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Delivery Governance Model

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Complex validations, such as:
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

Appian Reports are a sub-category of User Interfaces that share these characteristics:

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

Appian Reports are a sub-category of User Interfaces that share these characteristics:

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Dynamic Risk Mitigation

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Tags: Delivery, program management

How to Estimate your Appian Projects

joel.larin — Wed, 01 Mar 2023 19:51:45 GMT

Revision 36 posted to Guide by joel.larin on 3/1/2023 7:51:45 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Dynamic Risk Mitigation

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Delivery Governance Model

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Complex validations, such as:
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

Appian Reports are a sub-category of User Interfaces that share these characteristics:

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

Appian Reports are a sub-category of User Interfaces that share these characteristics:

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Dynamic Risk Mitigation

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

How to Estimate your Appian Projects

joel.larin — Wed, 01 Mar 2023 19:45:45 GMT

Revision 35 posted to Guide by joel.larin on 3/1/2023 7:45:45 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Dynamic Risk Mitigation

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Delivery Governance Model

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Complex validations, such as:
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

Appian Reports are a sub-category of User Interfaces that share these characteristics:

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

Appian Reports are a sub-category of User Interfaces that share these characteristics:

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

How to Estimate your Appian Projects

joel.larin — Wed, 01 Mar 2023 19:42:22 GMT

Revision 34 posted to Guide by joel.larin on 3/1/2023 7:42:22 PM

Skills Covered

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Dynamic Risk Mitigation

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

Delivery Governance Model

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integration
Security Requirements
Outliers

1) Records

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Complex validations, such as:
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

Appian Reports are a sub-category of User Interfaces that share these characteristics:

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

Appian Reports are a sub-category of User Interfaces that share these characteristics:

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.