Sounds like a great use of metrics Michelle!

Doug,

It sounds like despite our disparate domains we share some similar experiences.

Great point too that many gap analysis activities likely include an element of solution assessment. That makes perfect sense to me. Does this trigger any bells for anyone else reading? Perhaps what you’ve been calling gap analysis relates back to this BA task too?

My experiences have been pretty similar to what you mentioned, as they have been centered around evaluation of new acquisition functionality and then performing a compare/contrast exercise against the enterprise system. This highlights a couple of things: a)what each system can or cannot do and which does it better, and b) a general measurement of what each system is capable of handling. We are then able to assess whether to migrate functionality into the enterprise fold or convert the acquisition using the enterprise functionality. Also, we are able to use measurements of non-functional requirements for the acquisition in their current environment (e.g., number of transactions processed) as a baseline to ensure that we are improving performance with whatever solution is decided.

We also undertake a similar exercise when evaluating processes in the acquisition, which actually occurs before the technical assessment. In this case, we are seeking process inefficiencies and deficiencies to work with.

So I suspect that when a lot of people comment that they are performing gap analysis, that technique might actually be broken down into gap analysis and some degree of solution evaluation…at least on the front end of requirements.

I also agree with your statement about not always having the opportunity to evaluate a solution after the implementation. It always seem like there is a more pressing need with the limited resources we all work with these days.