Enterprise IDM: Part 2: Workflow

24 Oct 2005 The fact that a workflow is an essential part of Enterprise IDM was not that clear from the beginning. If it was, the Single Directory paradigm cannot ever appear. It took some years to realize this, but it is quite clear now. You just cannot sell an IDM product that does not include workflow or tightly integrates with it. Or more exactly, you can sell it, but you cannot effectively deploy it.

While still in a sales process, you promise the customer to customize the workflows exactly to his needs. The product has this neat workflow engine that even a trained monkey can configure, you see? And the customer swears that it has all the relevant workflows formalized and documented. You thing how easy will the part be and almost forget about workflows while preparing the project. As analysis begins, you will receive a pile of documets describing existing manual workflows and you start to process it and design the implementation. And there the first warning appears.

As you try to compose the mask screenshot of the workflow GUI, the customer asks:

Well, as you are in the "customer satisfaction business", you do that customization. If you have such a great product as we had, it is indeed very easy. Few hours of work. Negligible. You do it and you forget about it. But this was the first warning sign.

Later, after the design is nearly complete, you found out that the "old groupware tool" is in fact much more important than was expected. The documenatation on the manual workflow processes is in fact a bit outdated. The processes were adapted by changing the "groupware tool" directly, and the changes were not allways documented. And later you find out that part of the processes is still carried out "intuitively" by asking someone how to do it. These were not even mentioned in the documentation at all. And even the documented processes contained steps that were not strictly algorithmic, based on the principle "if it looks right then it may proceed".

If you have such a good product as we had, you can implement most of the functionality right away, customizing the workflows and user interface. Each "piece" will take you few hours and that can easily be lost in the overall project plan. But there is a lot of these little "pieces" that you must implement or compensate for. And if you keep a detailed record of work that you spent on project (as I do), you will soon find out that it takes tens of man-days that were not expected in the project plan.

Moral:

1. The things that are missing in the analysis are much more important that those that are included. Allways look for the missing things. Never allow yourself to consider analysis complete only because it is already 100 pages long. A 20 pages of analysis document with all important aspects mentioned in low detail may be perfectly OK, yet 200 pages of detailed descriptions may be totaly useless if it miss the important points.
2. A negligible amount of work repeated many times equals a lot of work. Do not underestimate customer's desire for "cosmetic changes". Especially in user interface and workflows.
3. A workflow is one of the most important parts of user provisioning. Maybe the most important part. Do not trust anoyne telling you that they will not use workflows. They will. Do not trust anyone telling you that they will use the default workflow. That will not suit them and you will have to customize the workflow anyway in order to make the solution work. And do not trust anyone telling you that they have all the existing workflows precisely documented. That's a myth.