Blogger: JP Morgenthal
I've avoided bloging about this topic, because of the obvious lack of means to describe the answer to the question posed in the topic. Pundits say that BPM and SOA are the "peanut butter and jelly" of IT. I'm of the mindset that BPM and SOA are as different as man and woman, but if they share one attribute its that they both suffer from a complexity of scoping. As for how BPM and SOA are really different, look for a podcast on that soon.
One of the biggest hurdles to scoping that I've recognized is that IT often lacks the breadth of understanding of available industry solutions across the diverse range of functions for which it needs to deliver solutions. Meanwhile, they are chartered with the requirement to deliver solutions to meet the business' needs defined by users without understanding of the implications of their request.
Here's a great real world scenario of what I'm talking about. Company A goes out and purchases software for managing travel expenditures. The software does 80%+ of what the organization needs, but due to the type of industry this company is in, there's some unique accounting rules, which the software does not support. Certainly there's a wide-range of solutions that can applied to this problem, and many IT professionals reading this are probably saying in the head, "oh, that's easy you just ....," wherein lies the problem.
Most IT professionals would come up with very reasonable and good solutions to THIS problem, but miss the fact that THIS problem shouldn't be solved in THIS software. In fact, there's a whole class of software that is designed to deal with this specific accounting problem and takes feeds directly from a number of data sources surrounding travel and expenses. I only know about this class of software because I was privileged enough to work on the design of a product to deal with this issue, otherwise, I would most likely have looked at ways to fix the problems at the source as requested by the business.
This relates to the scoping conundrum because the issue became apparent as part of an overall business process effort and, thus, was scoped as part of dealing with the issues surrounding travel and expense management. So, here was an intricate part of a BPM initiative that should have been completely out of scope.
While we cannot clearly answer the question posed in the title, I at least use the following guidelines to try to optimize the scoping issue:
1. Identify the differece between a feature and a requirement.
Many features are requested in order to make users' lives easier, which is important and needs to be taken seriously. However, usability aside, many feature requests are made to accommodate a poorly-designed business process. Sometimes the requirement can be accommodated through process re-engineering, thus allowing precious IT resources to focus on other more critical issues.
In this particular case, address the issue by scoping this as a BPM initiative, not an application development requirement.
2. Don't shoot the messenger
The most straightforward approach is not always the simplest. In many cases, the most straightforward approach is to fix the messenger, where the messenger is the application in which the user is having difficulty completing the task, so the request is to fix the messenger, when the best solution may be to move the task into an application where it's is more appropriately handled.
In this case, we need to expand scope and address how orchestration will be handled. This will result in less customization and less siloed solutions. It may, however, require a greater amount of integration.
3. Ensure the request directly addresses the goal for the BPM initiative
If the goal of the initiative is to reduce the time it takes to complete a process, and a particular requirement addresses costs, quality or some other issue ... remove it from scope or re-define the goal of the BPM initiative.
Of note, I believe that the only means the IT organization has at it's disposal to obtain breadth of understanding it needs to adequately and responsibly respond to the automation requests of the business is to leverage collaborative communications, both inside and outside the organization. Of course, I caveat that this would be bad practice around competitive advantages, but so many of an organizations' processes offer no direct competitive advantage and have been addressed by other businesses before.
Comments