Estimating Effort

When starting your BPM project it is often necessary to roughly estimate the expected effort. A process model can serve as a central artifact for estimation purposes. Avoid too fine grained estimations as they typically are not worth the effort.
Estimating Effort is also related to
  • Effort
  • POC
Estimating Effort

Avoiding Too Fine Grained Estimation

As a rule of thumb, the agile software development community nowadays keeps "effort for effort estimation" as low as possible or even consider it to be superfluous and waste of time and resources. We agree: on the level of software development, teams focused on implementing features and eliminating issues. It often doesn’t lead to valuable management insights to let the team spend time for estimating expected efforts.

However, on a management level one often "must have" estimations in order to secure budgets, get projects started, allocate needed resources and communicate expected time frames. The success factor is to do estimations on a very rough level and avoid spending too much time with details - the details more often than not developed differently than expected anyway. :-)

In our Camunda development team we only estimate "T-Shirt Size" categories (S, M, L, XL and XXL). Such an approach is sufficient for us to make roughly informed decisions about priority and return on investment.

t shirts

Having said that your organization may demand that you map such rough sizes to some measuring system already used, like e.g. story points or person days. To preserve the rough character, consider to map the sizes by using a series of sharply increasing numbers:

S

M

L

XL

XXL

2

5

13

50

200

Following the Customer Success Path

Much more important than very concrete numbers is an educated gut feeling. Therefore try to understand the influencing factors determining most of the effort by implementing a "lighthouse" process #1. When estimating your first BPM project consider the activities mentioned in Following the Customer Success Path and displayed here:

Understanding the Influencing Factors

After having developed your first "lighthouse" pilot process application project, consider that certain types of work necessary to implement next processes will basically cause repeating effort while the effort connected with other types of work will typically become small over time. Allow for some additional effort to improve your "lighthouse" pilot process #1 and to build your custom BPM platform when implementing the first processes.

You might get faster with every developed Process Application, because of gained experience (in analysis as well as implementation) and developed re-usable components. However, you might also face changing teams, fluctuation and new requirements. So this depends very much on your context.

Effort Patterns

Work Package

"Lighthouse"
Process #1

Process #2

Process #3

(1)

Setting up a
Development
Environment

Effort of Setting up an Environment

(2)

Modeling and
Understanding
Requirements

Effort of Modeling

Effort of Modeling

Effort of Modeling

(3)

Implementing
the Process
Application

Effort of Implementation

Effort of Implementation

Effort of Implementation

(4)

Going Live
with a Process

Effort of Going Live

Effort of Going Live

Effort of Going Live

(5)

Building a Custom
BPM Platform

Effort of Building a Platform

1 We assume that the effort of these activities might get smaller over time, too, because of people learning to build process applications and their overall increasing experience with Camunda.
Don’t misinterpret these work packages to be project phases following each other. As we agree with agile software development practices, the types of activities covered by these packages are typically carried out in several iterations. Each of those iterations is typically inspecting the previously achieved work results and adapting them based on the lessons learned. As a result we also continuously improve our understanding of requirements.

Effort of Setting up an Environment

Setting up a Development Environment

Getting your development environment(s) up to speed will typically follow these steps:

  • Installing needed developer tools.

    • Installing and customizing your IDE of choice (e.g. Eclipse).

    • Installing and configuring your build Tool of choice (e.g. Maven - incl. Camunda Nexus Access).

    • Setting up test servers with your application server of choice (e.g. Wildfly).

    • Configuring test databases with your database of choice (e.g. H2 for developing and Postgres for integration testing).

    • Setting up a functional project build pipeline including a sample process and a first test case.

  • Setting up stages on the way to production (e.g. test, integration and live system).

    • Installing and configuring the application servers.

    • Setting up and configuring databases.

    • Configuring network and firewall settings, with respect to enabling service access.

  • Setting up production environments.

    • Ordering hardware or virtual systems.

    • Installing and configuring the application servers.

    • Setting up and configuring databases.

    • Configuring network and firewall settings.

    • Connecting Camunda to a directory service (e.g. an LDAP based service).

Effort of Modeling

Modeling and Understanding Requirements

Understanding requirements typically encompasses the following activities:

  • Discovery of a strategic process and embedded decisions

  • Analysis and modeling of an operational process and embedded decision logic

  • Analysis of required data and data flow with respect to the process

  • Discovery of required services and already provided interfaces

  • Discovery of human tasks and design of screen/form mock-ups

The actual effort needed obviously varies with the size of the process, but also depends a lot on your current internal organizational maturity with respect to alignment of domain experts and IT staff.

Effort of Implementation

Implementing the Process Application

Implementing the Process Application includes test and deployment on local systems as well as test stage systems and typically consists of the following activities:

  • Taking care of used (persistent) data objects and expressions

  • Interfacing with existing back-end systems and services

  • Implementing additional services and requirements by means of conventional coding

  • Implementing task forms and other user interfaces for the process

It’s important to consider dependencies external from point of view of your team: your team’s effort in making it possible to call existing back-end systems by some meaningful services may vary between 0 (already enabled) to being close to impossible!

As you can use Camunda tasklist, develop your own custom tasklist/application or integrate with a preexisting third party tasklist, take particular focus on the fact that Deciding About Your Tasklist is one of the biggest factors influencing your overall effort!

Effort of Going Live

Going Live With a Process

Understand that going live with a process will almost always cause a certain amount effort. Specifically in Deploying your process application to a live system (depending on how close your organization and project is to continuous delivery).

But also consider that BPM efforts often need change management to implement adapted processes into an organization:

  • Defining organizational responsibilities for operations

  • Briefing and training of affected people

Effort of Building a Platform

Building a Custom BPM Platform

Depending on your very specific overall considerations in the domain of enterprise architecture you will want to build up a common platform enabling and easing your process application development efforts.

There is a tension you must consciously balance in the light of your specific circumstances: your first project will serve as a technological blueprint – but will also determine acceptance of your overall initiative. Consider:

  1. On one hand: Not to be relaxed about Best Practices! Decide about the very most important aspects of architecture, tooling, frameworks and methodology upfront.

    So what is important? Consider that some architecture aspects influence user acceptance very much (e.g. how tasks are presented, how operations are organized) and some things are necessary to show the benefit of BPM to management stakeholders (e.g. process reporting, KPI‘s).
  2. On the other hand: Keep in mind that you must deliver first results soon – so do not clarify all aspects in the first project! You will learn a lot during the initial projects which will allow you to continuously improve your decisions and practices. As a rule of thumb, try to do as little as possible as late as possible!

The overall effort for building your custom BPM Platform varies a lot depending on your goals, your type of processes, their intrinsic complexity, criticality, the needed scalability, etc…​ And it also depends on the maturity of your organization with respect to BPM efforts: is BPMN and a methodology to apply it already known? Are workflow and/or process engines already known? Is a service oriented architecture already established?

In general we want to discourage providing a custom framework for everything. This often leads to huge BPM platforms (based on Camunda) which are very expensive to maintain. Upgrading Camunda within these frameworks might get cumbersome. Users might feel uncomfortable, because they cannot use the normal Camunda documentation, as frameworks might change behavior or hide certain features. We recommend using as much default behavior as possible and allow autonomy for the teams using Camunda.

Bonus  Using a Process Model for Estimation

A process model can be seen as a central artifact for estimation purpose, as it indicates and visually maintains of a lot of the influencing factors mentioned above.

Here are the figures you could estimate:

"Invoice Receipt" Process

Work Package

Work Items and Estimates

(1)

Setting up a
Development
Environment

t shirt s

(2)

Modeling and
Understanding
Requirements

t shirt l

(3)

Implementing
the Process
Application

t shirt s

Setup project and build pipeline

t shirt s

Implement form for PDF upload and PDF display

t shirt s

Implement form Assign Approver

t shirt s

Implement form Approve Invoice

t shirt s

Implement form Review Invoice

t shirt s

Implement form Prepare Bank Transfer

t shirt s

Implement service adapter Archive Invoice

t shirt s

Implement data objects and expressions

(4)

Going Live
with a Process

t shirt m

(5)

Building a Custom
BPM Platform

Ships with Camunda

GREENFIELD
Using Camunda's Tasklist

t shirt m

Building a Custom Tasklist/Application (very simple)

t shirt xxl

Building a Custom Tasklist/Application (powerful)

To sum that up, you can count nine small S T-Shirts, one medium M T-Shirt and one large L T-Shirt, assuming you would use Camunda's Tasklist.

Let’s further assume that your organization’s development velocity roughly translates into the following mappings:

t shirt s

t shirt m

t shirt l

t shirt xl

t shirt xxl

Person Days

1

5

13

50

200

Needed Packages

9

1

1

0

0

In that case your calculation leads you to 27 person days. However, when needing to translate into person days do not suggest a high degree of accuracy. Take it as a rough estimation to differentiate between easy and more complex requirements. This consideration could lead you to settle with an overall effort of around 10-50 person days. Building a powerful custom tasklist/application would obviously add more effort - very much depending on the sophistication of such an undertaking it could easily translate into more than 200 person days.

All this always depends on your organization, people and skills. We regularly see environments within which just doing an internet search is actually a bit of effort, as security policies prevent developers from working productively. Once you gain some real life experience with such rough estimates in your context, a translation of t-shirt sizes into roughly equivalent person days will become more and more accurate (or more and more unnecessary ;-).

No guarantee - The statements made in this publication are recommendations based on the practical experience of the authors. They are not part of Camunda’s official product documentation. Camunda cannot accept any responsibility for the accuracy or timeliness of the statements made. If examples of source code are shown, a total absence of errors in the provided source code cannot be guaranteed. Liability for any damage resulting from the application of the recommendations presented here, is excluded.

Copyright © Camunda Services GmbH - All rights reserved. The disclosure of the information presented here is only permitted with written consent of Camunda Services GmbH.