How to Estimate your Appian Projects

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%.

1. Analogous Estimation
2. 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.

1. Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
2. Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
3. Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
   example 1).
4. Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
   Subject Matter Experts (see note below).
5. 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.
6. Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
7. 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.

1. Records
2. Processes
3. User Interfaces
4. Reports
5. Integrations
6. Security Requirements
7. 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.

1. Delivery Methodology - Agile preferred and recommended.
2. Self-managed vs Appian cloud - Appian cloud is preferred.
3. Regulatory Requirements - for example GxP for Pharmaceutical Companies.
4. 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.

1. Project 001 - Project Description for ROM Estimate.docx
2. Repeatable Template - Use Case Scoping and Estimation.docx
3. Indicative Examples - Factors and Estimates.xlsx