UAT and requirements gathering

In provisioning projects requirements gathering and UAT testing is always an interesting area. The general problem with UAT and system level testing is that in order for the testing to be useful you really need to know what result is the correct result and what is a failure.

When you write bespoke software you can usually find the answer to this question in the design which in turn is derived from the functional requirements which are derived from the business requirements. In a typical IAM implementation on the other hand you tend to use very feature rich platforms that provides huge amounts of functionality most of which you will never use in any given project. It is also often hard to shut down this "bonus functionality" so the functionality often is available even if it really shouldn't be used. Many times when you get to UAT the testers starts touching all kinds of buttons and levers and unless you have an experienced team that has spent substantial amount of time on actively locking things down you will have some issues with this.

Business process wise IAM implementations can fall on anywhere scale ranging from totally transformative to literal refactoring where the business process doesn't change at all. In the first case the challenge is that the UAT needs to reflect the new business process and you also need to ensure that the new business process actually supports all the functions that the business needs. In the second case things are easier because you basically just need to capture an already existing process.

No matter the strategic focus of the IAM project a proper UAT needs to be business process focused. The whole point of UAT is to ensure that all business critical processes are present and are working as expected or at least in a way that is acceptable. The irony is of course that if you discover substantial process breaks in the UAT you are usually in deep trouble as it usually is too late to fix things before the planned go live.

The best way to avoid this situation is to ensure that you do a form of dry run UAT very early in the process. In my experience one of the best ways to do this is to utilize simple Visio workflows. You start with the requirements, which usually are more or less useless, and create Visio workflows. You then show the workflows for the people that knows or should know the business process. These people can rarely tell you what is needed but they can usually tell you if you get it wrong or tell you things that you should take into considerations. After a couple of cycles you usually have a pretty good process and you have also gained the buy in from one of the stakeholders.

If your architect is experienced he or she can usually produce a pretty good set of flows that can act as a starting point. Most more sophisticated consultancy organizations will be able to provide a standard set of flows as well. If your implementation team starts coding without first establishing, vetting and communicating the business process it is time to start getting alarmed. The project may still deliver successfully but it will most likely have a very painful UAT or even worse a very painful go live in front of it.