Steps for Implementing a BPM Project in your Company

BPM projects have the potential to bring about a step change in your business – but only if planned and executed correctly. Your strategy as you plan this project will have a direct effect on this outcome. This article provides several guidelines for a successful BPM project strategy.

Choosing your first BPM project

The first BPM project within an organization should be carefully selected.  A good starting point is to assess where the “Quick Wins” are.  The key principles you can utilize in deciding which process will be your first process for implementation are:

  • High business impact (demonstrating a clear Return on Investment) with a low risk to the business.
  • A well understood/defined process (ideally) that is feasible to change/automate.
  • Stakeholders and Business Owner cooperation.
  • Tight scope
  • Demonstrable business benefit in rapid timescales e.g. 12-16 weeks
  • Low-to-medium complexity (e.g. with integrations, other departments, external users, etc.).

Project Delivery Approach

We recommend, wherever feasible, to adopt an Agile/SCRUM approach to BPM project management and a focus on developing applications that can be easily modified according to changing conditions. We will not elaborate in too much detail on the SCRUM approach here (learn more about SCRUM) but rather provide some pointers on how it can be adapted to BPM. We called this adaptation ‘Evolutionary BPM’ methodology.

Project Phases

BPM-enabled change can be viewed as a cycle of continuous improvement:

BPM Lifecycle

A cycle of improvement as shown above can then be seen to represent a phase in the project, with analysis of the current state being the first starting point.

Phase 1 of the project should look to deliver business benefit in rapid timescales. Using SCRUM, this can be shortened to a sprint of 2-4 weeks.

Phase 1 should then be monitored, with feedback on this first iteration, as well as any other requirements, being placed on the product backlog for further analysis, design, development and deployment.

The following diagram illustrates our recommended approach for a BPM project using SCRUM:


Project Roles

There are a number of roles critical to the success of a BPM project:

Business Process Owner (SCRUM Product Owner)

A Process Owner must be identified from the onset.  There can be only one process owner who has both the authority and passion to agree the process design, and manage the performance of the organization regarding the process.

Business Manager (SCRUM Master)

Reporting to the Business Process Owner, Business Manager (SCRUM Master) is a key stakeholders in terms of defining the required process and driving its adoption.  Much like End Users, their early engagement in the change is key to delivering a successful project.

BPM Product Specialists (SCRUM Team)

This team takes the user requirements, drafts the functional specification in line with the architecture, and then configures the process’s activities. They may also be required to create gauges and reports once the process is configured.

Additional Roles:

Subject Matter Expert (SME)

A SME may be involved in designing and agreeing on the process, and then administrating and maintaining the process in future.  The SME is someone with extensive experience in the business area in question, who is empowered to agree on changes to the process from the business.

End User

End User’s and their buy-in to the process automation are key to the success of the project.  Engaging with the end users early on so they feel ownership of the change process rather than as an after-thought is key to successful change management.

Business Process Analyst

The business process analyst is responsible for analyzing, modelling and documenting the business requirements, and agreeing these with the Business Process Owner/SMEs. The workflow can be documented directly within the BPM software.

Enterprise Architect

For complex projects, especially those involving integrations, an Enterprise Architect may be responsible for understanding high level requirements and drafting the workflow application design.  They should be able to draw upon a wealth of BPM and solution delivery experience, champion BPM within the wider community, and be aware of the process artifacts available from previous implementations.


Get StartedAt the start of any BPM project it is always very important to understand the specific business challenge that needs to be addressed, the way it will be measured and the processes that are affected.

The main focus at this stage of the project is to ensure that business and technical stakeholders understand what is expected of them and how the project will move forward.

The key deliverables for this phase will include agreement on the following:

  • Vision statement with business benefits mapped out.
  • A high level project plan with agreed milestones.
  • Named resources for the project team, team structure (roles and responsibilities) and agreed upon project governance model, e.g. weekly review meetings.
  • High-level agreement on the scope of work. This will later be validated as the project progresses, and should indicate at a minimum which requirements are mandatory, and which are optional for the delivery of the first release. Preferably it should include the process flows to be developed at a high level.
  • Agreed deliverables and who will be responsible for delivering them.
  • Agreement on budget and the way costs will be managed and recovered.

Requirements Gathering

Through the requirements gathering and process analysis phase, you need to:

  • Ensure the business requirements have been captured to a level of detail that will ensure the development team can start designing the process.
  • Ensure that this forms the agreed scope of work for the first iteration and meets the expectation and is approved by the end users and stakeholders.


Mobilizing the relevant stakeholders is one of the greatest challenges associated with implementing a process. This too-often-neglected step is crucial to on-time delivery and satisfactory process deployment.

Activities that require stakeholder involvement during the project include the following:

  • Consult with stakeholders on design issues.
  • Keep stakeholders up-to-date on what the developers have achieved. We advise using a SCRUM Board for this purpose. This board clearly shows who is working on what, what comes next (To Do) and how much time is remaining to complete.
  • Encourage stakeholders to continually provide input.
  • Make stakeholders feel that they are co-owners of the development process.


The Envisioning Workshop is designed to help you identify and prioritize Strategic Business Objectives, related processes and the metrics used to measure the identified processes.

Using this information, it is possible to identify, quantify and discuss any “quick wins” that will form the basis of a potential Business Process Management Proof of Concept (PoC) or project and realize demonstrable value to the stakeholders.


case-studies2The Discovery Workshop comes in many forms and usually follows the Envisioning Workshop.  When you have already identified a “candidate” process the Discovery Workshop ensures that the business and functional requirements can be captured in a structured manner.

The main purpose of the workshop approach is that all aspects are considered when compiling a business case. This supports the generation of a PoC and the ability to implement the project.

Using Agile/SCRUM, you can begin to actually build the first prototype of the process in this workshop.

Through the requirements gathering and process analysis phase, you need to:

  • Ensure the business requirements have been captured to a level of detail that will ensure the development team can start designing the process.
  • Ensure that this forms the agreed upon scope of work for the first iteration, meets expectations and is approved by the end users and stakeholders.


In the estimation stage, the SCRUM team estimates the work associated with each feature. This is important in order to understand the size of the project, and to decide which features will be included in each sprint. The team should then rank the features according to their importance.


This stage includes both design and development of the solution in an agile manner.


A design is required for every piece of development. Regardless of project methodology, a design is required by the developers to ensure they are interpreting business requirements correctly.

Myth:  “Agile/SCRUM means no design”. 

Reality: Agile/SCRUM may mean a design that evolves over time and no ‘Big Design Up Front’, but it does not mean ‘no design’!


Create short, concise design documents, called Speclets, which include UI’s, Business rules, Reusable components and Process flows.

Designing the Workflow

Having gathered the business requirements it is important to define the process in suitable detail for implementation stages. Getting this wrong will negatively impact project delivery and business user expectations.

Key Design Considerations

P12WorkflowComplete2rior to creating any process, you should consider the following:

  • What is the high level process and what does it do?
  • Initiating the workflow – a human or automated event?
  • What activities should the workflow include?
  • What is the desired activity type (web-form, email, triggering external systems into action) for each of these activities?
  • Who will be performing the task and who should the tasks be handed to?
  • User groups and associated permissions
  • The look-and-feel of web-forms

Using SCRUM, you will maintain a product Backlog – a document including all the features that should be included in the solution. Strive to describe features in terms of how they will be used, as ‘user stories’ or ‘use cases’.


The development team should work hand in hand with the SMEs and Business Analysts to understand the high level requirements, and drill them down to a lower level of detail.

If Agile/SCRUM approach is adopted, the build phase will be closely interlinked with getting approval from users once some functionality has been developed. The design can then be adapted to ensure it meets end user need and expectations.

To develop a process you carry out the following steps as a minimum requirement:

  • Create a process
  • Add activities
  • Implement business rules
  • Connect activities
  • Assign permissions
  • Unit test the package


SCRUM BPMaSCRUM development is achieved in Sprints. Start the Sprint with a planning meeting, where you decide which features from the backlog will be included in the sprint.

Conduct daily stand-up meetings attended by all team members. At the end of the sprint hold a retrospective meeting to review progress and make improvements for the next sprint.


While out of the scope of this article, the next stages in the BPM project are Testing and Deployment (called ‘Transition’ in SCRUM). These stages are obviously of critical importance, and we plan to devote a subsequent post to them.

Top things to remember

  • Think BIG but start small. Plan for iterations, and publicize/vocalize this is what is going to happen. Communication is KEY.
  • Make sure your team are properly trained before starting development.
  • Keep it simple – simple applications are much faster to develop and most likely capturing 80% of the requirements.
  • Don’t try to build an entire application that meets all requirements in the first iteration (i.e. don’t try to ‘boil the ocean’).
  • Use an Agile/SCRUM approach where possible.

PNMsoft has over 17 years of experience planning and executing successful BPM projects for leading global organizations. Our Evolutionary BPM methodology has a 95% success rate, one of the highest in the industry. We would be happy to share our knowledge with you and assist you with your BPM initiative.

Get Evolutionary BPM Methodology White Paper:




Leave a Reply

Your email address will not be published. Required fields are marked *