BPM – Recommended Project Delivery Approach

The implementation of an automated process can be a simple process but is made more complex if not done a consistent and pragmatic way.

It is recommended that where ever possible an agile design and development approach be adopted. This time-boxed approach ensures that a specific scope of work i.e. a selected group of functionality can be designed and implemented in a way that delivers value to users and incrementally increases the adoption of the automated process across a department and wider organisation.

In most cases the risks due to delays and non delivery do not come from poor development but from a lack of good planning and preparation. It is therefore extremely important to ensure that the correct level detail is defined during the scoping and design stages.

Recommended Project Delivery Approach

The following high level activities describe our recommended approach initiated a process automation project. The duration and order of each may change for some projects as not all are the same.

Project Initiation and Scoping

At the start of any process automation project it is always very important to understand the specific business problem that needs to be addressed, the way it will 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:

• A project plan with agreed milestones
• Named resources for the project team, team structure (roles and responsibilities) and how the project will be managed and reviewed e.g. weekly review meetings etc.
• High-level agreement on the scope of work. This will later be validated and finalised during the analysis and design phase but should not change dramatically as it will cause delays.
• Agreed deliverables and who will be responsible for delivering them
• Agreement on budget and the way costs will be managed and recovered.

Initiate Training

This step is typically something that end users always try to avoid but to ensure all stakeholders and the development team have an appropriate level of understanding it is recommended that training take place prior to starting the functional design.

In some cases this should be completed for specific individuals e.g. Business Analysts and senior stakeholders before starting requirements gathering activities.

Installation

Typically a day is required depending on the type of project and the complexity of the environment.

Analysis to Baseline Requirements

Ensure that business requirements design has been completed to a level of detail that will ensure the development team can start building the process.

Ensure that this forms the agreed scope of work for the first iteration and meets the expectations and is approved by the end users and stakeholders.

Designing the Workflow

Workflow design can take anything from a day (demo or small project) to weeks for larger complex projects.

A key factor that will influence the design time is how much clarification will be required from end users if the requirements have not been well defined upfront. This will obviously have a longer term impact and increase the risk of late or non delivery if not controlled from early on.

The functional design does not have to be completed in its entirety but must be comprehensive and identify what is known and what is to be defined during the iterative development cycle.

At a minimum the following must be defined during design:

• The process and related activities
• Forms and their design
• Data entities on each of the forms
• Business rules
• User roles and permissions for each activity of the process
• Notifications and emails
• Manual and automated interfaces
• Process metrics

The benefit of adopting an agile approach is that the design and development is done in short, time boxed stages and therefore on completing a some functionality, it can be released to users so they can give their input. This is then fed back to the development team and therefore ensures the project is not taken off track due to scope creep.

Workflow Development

The development process should conform to an agile approach and therefore it will be closely interlinked with getting approval from users once some functionality has been developed. The design can then be adapted (within agreed tolerances) to ensure it meets end user need and expectations.

Development can take anywhere between two to 3 days and weeks, depending on the complexity of the process and the scope of the first iteration. Aspects that factor into this include the intended number of web-forms (an attractive GUI may also take a while to accomplish) the number and complexity of workflow activities and integration points with other systems.

Business User Reviews

Although design documents and technical documents are an essential part of a successful project, stakeholders and developers must be presented with a concrete, visual process.

Consider having a weekly get-together with stakeholders in which they will be presented with what the project progress is and what the development have been able to achieve since the last review. Use this meeting to explain what the project and development plan is for the next couple of weeks.

This approach ensures that the original paper design ‘comes to life’ and meets the expectations of the stakeholders. Refinements can be made to the original design but it is important that the project scope should not change as this will introduce scope creep and the risk of late or non delivery.

Testing

Testing is normally done at various points during the development cycle and therefore should be well defined and mandated to ensure a quality solution is delivered.

Deployment to Production

It is good practice to involve the operation and support team who be taking over the longer term management and support of the deployed solution for this task.

Involving them early on during deployment testing is usually an opportune time to ensure knowledge transfer and continuity. Training will be required for this team but in most cases training a system administrator will be sufficient for a start. Additional training can be provided as required.

Further Enhancements and Process Improvement Phases

It is recommended that advanced metrics, dashboards and reports are implemented during secondary phases i.e. after the initial deployment. The benefit this has is that the process can be bed down and once the users are more familiar and comfortable with the new automated environment they can focus on process specific improvements and decision making enhancements e.g. ad-hoc reports and dashboards.