The first CR deployment, under my supervision, on the Production server and the overall implementation was smooth. To my astonishment, users have complained very little. Further improvements are on their way. This time I have not left any test cases untested, however trivial, and hence my testing is going a bit smoother. A heart-felt thanks to my team that made is successful. Hopefully, I don’t leave any scenario that can cause problems when the subsequent CRs are deployed on the Production. But, this blog is not about my pre-Production stint but pre-pre-Production.
BPM software intends to rationalize the weight of exiting business conducting methodologies on the various resources employed by an organization. With the help of BPM software, the organization envisages a digitization of its existing business processes and thus increases the efficiency and brings transparency to the organization’s operations.
The success of such a humungous task requires a great deal of patience and understanding of people’s requirements. The people include those who make up the organization’s senior management and those who run the daily operations. And these are the people who will use the BPM software day in and day out at various levels to earn revenue for the organization. In my experience, it was not the digitization of the existing business process that made its way into the BRD but it was the people’s requirements from the BPM that made its way into the BRD. It requires many meetings to first understand the business process itself and then understand the people’s requirement. The preceding Project Lead would definitely testify this. If the process and requirements are not clear and not concurred by all then the project is doomed to fail.
The second difficulty level is converting the understanding of the process and the requirements into BRD. It is definitely easy to write A wants banana, B wants apple and both can get it by asking C. But it is difficult to write A will have to go to C to ask for banana and apple and after A has got both, A will give apple to B. This requires the identification of responsibility, ownership and accountability of people at various levels in the organization. Further, these identifications should be in commensurate with the organization’s business strategies and hierarchy levels. Any goof up in this level leads to an unsaid tension among people and thereby effecting the successful implementation of software.
The third difficulty level is setting of check-points, positioning of u-turns and placing of exit routes. To what extent this 3-part ensemble need to be incorporated in the new digitized process is in itself a huge task. Given basic human nature, the 3-part ensemble would seem like “minimal check-points, lots of u-turns and exit route at every possible block”. Any change, however trivial, in the digitized process will be welcomed with a great resistance.
In my organization, with the amount of time spent on such a project at various levels, I am clear on one aspect. It is very difficult to make people understand “to change their view such that they are able to adapt themselves with the software”. With each modification aimed at accommodating the change requests from users, a new change request is already born. It is not BRD that did not capture the requirements but it was the lack of conviction by the people to adapt themselves with the software.