I have begun working for a company that resell BPM products, for improvement and automation, including small Sw development sometimes.

Sadly, they have a colosal rate of failure when estimating time and other resources. I have been asked to provide ideas from my agile/waterfall developer experiences, but I do realize this is not a sw project entirely.

I find that processes are design/maintenance heavy, and that have more people involved, sometimes unwilling to review/help on their own process automation.

I have seen handy practices from Sw projects to be present in BPM tools (versioning, project descriptors), but that's pretty much it.

This makes me wonder, could they have metrics in common? Or even a methodology? Or are they 2 different worlds?

  • What are the root causes in your opinion for the delay? Is it attitude (human factor) or scope creep or technology? Commented May 8, 2014 at 16:58
  • The problem is on the way we work, many just implement a process in a BPM software immediately, but it leads to massive changes (customers requests, code re-factoring, infrastructure changes). I just think some planning, atomizing tasks and less reliance on the tool could help but I dunno much about processes tbh
    – javaNoober
    Commented May 12, 2014 at 20:42

3 Answers 3


It sounds like root cause is less the implementation of the software (or even the features in it) and more unthinking application of the default processes your software ships with. I would say you have two very different efforts that are being co-mingled - a software configuration process (resell, install, configure) and a business process re-engineering effort. I would suspect that many companies looking for BPM software are also looking for some process re-engineering.

You might consider trying to track and split the two separately, at least internally. One potential methodology that might help is to think of the two in terms of the Cynefin framework (here's a good description http://www.scrumsense.com/blog/cynefin-framework)

I see the two efforts like this:

A) Select, install, config the appropriate BPM SW - this is a complicated problem, and I would expect the one you already have decent processes for Sense - get the initial requirements Analyse - understand the appropriate config and customization based on what you know Respond - figure out how actually implement

B) Work with the company to determine which processes they clearly wish to keep static and which have new (potentially implicit) requirements - this is a complex problem, and calls for a methodology more along the lines of a Scrum, Lean, or Kanban approach Probe - quickly model the new / changing processes in a working instance Sense - review (a la sprint review) with the client, get stakeholder feedback on what worked and what didn't Respond - Amplify the positive signals (this worked, do more things like this, in the way you did them last sprint) and dampen the negative signals

If you can get clients to agree to model their contracts with you on this framework, so much the better; if not it is still an approach that allows you to clearly delineate where you can and cannot predict work and resourcing. At the very least you can have the conversation about your 'a colossal rate of failure when estimating time and other resources' in the context of a new framework, rather than in a witchhunt. Sounds very challenging - good luck!


BPM is great at automating processes so in principle you can define your delivery process and run it. I have on many occasion documented SDLCs using BPMN.

However, the SDLC and various methodologies are fairly common and several existing tools are specialized in it. Therefore BPM is somewhat at a disadvantage in the sense that you have to reinvent the wheel and custom develop many features which come out of the box.

This said, as you pointed out software development is about implementing change as is often BPM in practice. That mean that there are a lot of similarities in term of approach, methodologies and terminologies.


BPM software implementations are difficult because it's like changing an aircraft engine while the plane is still flying. You can't tell the company 'ok, you have to stop making widgets for two weeks while we change your processes'.

In addition, some of the people working in the company might feel (possibly justifiably so) that their jobs will be put at risk if the BPM implementation is successful. This is different from your typical app development where the stakeholders and project participants typically want the project to succeed.

Another factor to consider is that there are usually interfaces to other systems e.g. accounting.

The following really are essential for a successful implementation:
*A step by step process so as not to overextend the organization (try to avoid a 'big bang' changeover),
*Early involvement of users with simple tools so that the results are supported and in the end are accepted
*Inclusion of IT-people so that the integrations are technically feasible
*Inclusion of a process manager who has a general overview
*Assertive project management and clear statements from management so that everybody is pulling together.

So you need to have small incremental measurable improvements, as is typical in Agile, but not to lose sight of the bigger picture. Getting a small group from the client company as early adapters is usually a good step, as you can use a more Agile approach in this context.

You should also consider using Agile methodologies in the design stage - (try replacing 'software' with 'design documentation' in the Agile Manifesto) - so, lots of iterations of the design process with small incremental improvements and granularity of detail before starting to actually configure/customize the BPM software.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.