How many IT projects have you seen where the business requirements weren’t implemented or only partly implemented? In my experience, the business blames IT for not following their requirements and IT blames the business for not giving clear enough requirements. But it doesn’t matter where the blame lies the better question is, what can be done to avoid such an outcome?
Let’s start with the age old question of, what’s required to get IT and the business aligned? And equally important, how do we keep them aligned beyond the first meeting? It’s not as simple as asking the business to describe their requirements as a process model. Although process models are a good start and an important approach to build on, I believe we can get much closer to an approach that business and IT can follow together.
Here is the recipe I have in mind:
1. Tools alone are not sufficient enough for successful business / IT alignment and good project results. Solid project management and communication structures, together with a good methodology, are crucial if an organization hopes to achieve good results with Business Process Management.
- Business people need a way to capture and document processes with all the elements important to them. The tool that supports this activity has to be usable by non-developers.
2. Processes that have been created by the business need to be communicated to IT in a way that they can use the model as a starting point for the technical implementation. Without having to re-model the process from scratch. So you need a model transition from a process design tool to a full-fledged developer environment without media breaks due to different model formats and such.
3. In the course of the technical implementation of a process, the model always gets changed (i.e., to illustrate exception handling, task locking, etc.). Now IT needs a mechanism to communicate these model changes back to the business. Why? Because the business needs to be able to understand if the original intent of the process logic is still represented in the technical model.
4. Next you need a way of comparing the technical model to the original model and also a mechanism that allows the business user to approve or reject any changes in the technical model. This approval / rejection mechanism also implies that we need the ability to go back and forth iteratively between the line of business and IT during the process implementation phase until the result satisfies both sides.
Having such an iterative approach that works through bi-directional communication between the business and IT means that all subsequent change requests can be handled in a structured way. If the business has new ideas a few months later, the above mechanism would allow for transparent collaboration. Also, if the IT infrastructure changes these changes can be communicated back to the process owner on the business side.
5. For all of the above, it is important to route and track interactions between “the business guys” and “the IT guys”. Email notifications for all involved parties and task tracking of what needs to happen next with the process model will ensure delays due to a lack of transparency don’t become a problem.
6. Last but not least, the tools should provide transparency between the process lifecycle and the lifecycle of services, as well as the data model that feeds processes. This might not be obvious to everyone immediately, but trying to manage dependencies between processes and the underlying service landscape can become a huge challenge very quickly if you don’t have a good solution in place.
Do you think these 6 steps could help better align IT and the business in their quest to communicate the right requirements and have a successful BPM implementation?