Change your business process or Software?

Have you been in situations were you have to decide if the software has to be changed or the process? And what do you do?
Most of the times I saw in projects that both did not changed at all. The so called "work around" are defined. Only they are often poorly managed.

You have several types of projects. On one side there is the newly build project. On the other side the fully standard application implementation. And off course all variants in between.
I think there is at least one similarity between these projects. At a certain point you have to decide whether to change the code or the process. Even if you accept the workaround you have to decide after a certain period of time if you change the code or process. In the first situation the workaround is no longer necessary. In the last situation it becomes standard procedure.

On a quest for searching for figures what changes in procedures cost I came to this article:

Which Is Easier: Changing Business Processes or Changing Software? by Loretta M. DeLuca, August 20, 2007

Quote: And you probably don't believe this either, but it really is easier to change your business process rather than your software. Believe me, because I do hate to say, "I told you so."

In this case for us testers there is still a job to do. Though the code doesn't change, you still have to verify that the software indeed matches the business process. The focus will lie on the User Acceptance test.

If the code changes you also have to test the impact of that change onto the system. And the impact of the change on processes. My experience is that certain changes are found in a late stadium of the project. This will make impact analysis mostly focusing on the impact of the system under test rather then measuring the impact on business processes. This lead me to the following article.

Life Cycle for Change Management in Business Processes using Semantic Technologies by Uttam Kumar Tripathi, Knut Hinkelmann and Daniela Feldkamp, Journal of computers, vol. 3, 1 January 2008

Quote: In a fast changing market environment the task Business. Business of reducing the downtime for change management of business processes has high importance. Ensuring that IT reflects the updated business requirement is an important task related to change management in software development.

In that article they defined a process how to manage process changes into Software changes. If I interpreted it correctly they translated the process changes in a formal language and made relationships towards code. I think in according to that paper it is already easier to tell what impact changes in processes have on code. This might help us identify the areas to re-test.

Software Process Improvement from PelicanWeb gives a graphical overview how to measure holes when new requirements are introduced and what the impact is on the project.

Measuring holes and creating new procedures makes me think that we IT-people always tending to re-invent the wheel. Why should be do it when there is more information available related to organizations. In previous lessons I followed related to Organizational Changes I was confronted with a model as described in the article below. This model is written towards organizational changes. Why not use it on detailed level and combine it with the impact towards systems? Perhaps you, reader, have a suggestion how to start?

The Matrix of Change: A Tool for Business Process Reengineering by Erik Brynjolfsson, Amy Austin Renshaw and Marshall van Alstyne, 1997

Quote: The Matrix of Change can help managers identify critical interactions among processes

I know that there are quite good applications to monitor changes in systems, for example cc Harvest or PVCS Dimensions. I'm not sure if they have the capability to monitor changes in processes and procedures.

Perhaps we need another document as well as test basis. A map on how the software is related to requirements and also business processes. It might help to verify if RFC's are judged correctly according their impact. It also might help to identify the impact of changes based on the relationship towards systems. And also when a work around is accepted, what the impact on processes would be. Based on the impact on the process the life cycle of work-around could be defined and also monitored.

Perhaps in Agile projects such a matrix can help identifying the content of the next iteration.

What do you think? Is there already such a framework? Can we use it? Do we need it?