The differences between BPM projects and IT projects

Although all BPM projects should be considered as IT projects and should follow the same development methodology – there are a few “subtle” differences:

Missing the Business Pain
In an IT project – it’s simple. If the application is built to spec – project success. If the application has additional bells and whistles – even better!
In a BPM project I can build the workflow to spec, add bells and whistles until I’m blue in the face. But if I haven’t solved the business pain – the project is doomed.
Ways I try to resolve the problem:
1. Find the business pain. If the problem is a lack of visibility – I’ll create additional reports. If the problem is bottlenecks – I’ll build the workflow to bypass the bottleneck. If the problem is employee performance – I’ll add additional reminders, escalations and SLA reports.
2. Get user feedback. I constantly ask the business users and end-users “Will this solve the problem?”. Spending time on ensuring that a solution actually solves the business pain is always better value than any application bells or whistles.

Business Requirements will change
IT projects are straight forward. Build the application according to the technical specification. If all is completed I’ll get sign-off on the project. What’s the worst case scenario? The application needs additional functionality – the customer will pay for phase two.
In BPM projects its different. Business requirements change all the time. By the time I’ve finished the initial development, the process has changed four times and the system in its current form cannot go-live. Trying to go-live with an unfit process is just a disaster in waiting. Even the best business analyst cannot foresee all of the required process functionalities. Some things can only be seen when the system is up and running.
I’ve found that understanding that a BPM project will always change, and embedding this in the project costs and timeframe is better than trying to deliver an usable (although up to spec) solution.
Ways to resolve:
1. Shorter Phases. The quicker the first go-live happens – the better. Phase One usually takes me 5 weeks (from design to go-live). Additional changes – another fortnight (but that is after the process is already gone-live)
2. Good Cop – Bad Cop: Always go into a project with a project manager. Even with small implementations. Let them take the brunt of the change requests. Ensure the project manager postpones any additional changes to “Phase 1b”. It’s always easier implementing changes once the system is up and running.

Internal Politics
All BPM projects, are at their core, organisational changes. They change the way employees work.
Employees, like all human beings, don’t like change. People tend to stick to their old and familiar environments and work methods, as bad as they might be.
Unlike IT projects where I’ll build an application and the end users will either use it or not, BPM projects add tasks to their workload, make their workload more “efficient”, or even worse – replace their work with an automated system. One of the biggest hurdles to jump is user acceptance.
Ways to resolve:
1. Awareness: Be aware that implementing changes will cause worry (worry from the unknown, worry about losing their job, prestige or power). The more information that I can give employees about the changes and the more people that I can show the system to and get their support – the better. User acceptance is crucial for project success.
2. Carrot and stick approach. I try to ensure that the new system gives employees something to be happy about (a feature that saves them time doing tedious work, a feature that enables them to show their managers what a great person they are, etc..). On the other hand I try to ensure that the project sponsor is strong enough to quash any chance of “revolt”. User acceptance is easier if the employees know that the management are completely behind the changes, and that they will go forward with the changes.

Testing
In IT projects the bugs are usually technical.
In BPM projects the main bugs are logical. The workflow might run smoothly with no technical bugs, but if the process missed a critical logic, or the business rules are working but I didn’t take into consideration that “odd irregularity” – I will be doing rework.
Ways to resolve:
In BPM projects there needs to be more business user reviews and end-user reviews. QA still test the technical side but the emphasis is on business reviews.
When I’m doing a project at a customer site, I usually do a presentation every Friday to the business users to show them what I built. I see it as one of the most important tasks of the project. During the presentation I usually get a few change requests. If the requests are simple to do and won’t delay the project deadline then I’ll implement them (even if they are not in the project scope). People respond well if I facilitate their personal requests. It makes my life easier on in the project. They get excited. They participate more. They see the project as their creation, not just another bit of software.