Expectations and Changes

When doing a Siebel project, there will always be a balancing act between managing client expectations and delivering everything the customer wants. I am not even trying to finesse when I say managing client expectations. The way I put it in that sentence, you may have inferred I meant not delivering what the customer wants. But that is not really the case, as frequently, the client does not necessarily know what they want, or their understanding of what they want evolves as they understand the capabilities and the implications of a CRM strategy/product.

We see this unfold in different ways on different projects. In a green field implementation (new to Siebel), Phase I is typically a data model implementation where the majority of the development work revolves around building views. Now there is obviously a lot that goes on behind the scenes, but from a Client's point of view, we are mostly showing them views, and using a view as a way to communicate the concepts of a data model. That is, the view becomes the way to communicate relationships and attributes. The presence or absence of a field on a view becomes a visual indicator of whether a logical attribute exists or not in our build out. An attribute expressed as a single value field in an applet provides a visual cue that a user can only enter one value. Because the views provide extensive visual reinforcement, it is easy for stakeholders to identify gaps through the testing and acceptance process by saying, ahah, I do not see this field, or I need to enter more than one of that value, or their needs to be a view linking these two objects.

Integration based projects tend not to have the same issues when integrating to a legacy system as there are typically a pair of technical architect types that are fairly knowledgeable about the preexisting data models of each application. The project is mainly a matter of synchronizing these efforts. Testing and user acceptance though can again identify visually when a field or record set is blank to recognize that a gap exists.

Where I am leading to with all this is the nature of an automation oriented project. Automation is by it's nature typically new. Perhaps the steps have existed, but the mechanisms we are using to automate, to add speed to the process, have never existed before. This adds some expectation management issues that are a bit different than in other types of projects. The types of changes necessary have an added dimension. Gaps in the specifications will likely be caught dring the testing phase, such as a field not being populated or a decision branch executing on the wrong condition. The added dimension is time and frequency. For instance, a popular way to automate processes is to add reminders to a process when steps are not executed, or to change a status of a record to indicate an escalation in priority or status. I would posit that users do not really know how frequently they will want to be reminded because they do not necessarily have a sense of the scale or frequency of the events. Frequently, during an interdepartmental process, one department may perceive the severity of an issue as higher that the department they are working with. These are important considerations because a user that is reminded too frequently (when in fact they are aware of a task but are waiting on other deliverables in the normal course of performing it) will begin to ignore the reminders. Being informed of a number of outstanding items on a too frequent basis will cause us to phase it out as anything that can be happening so frequently is typically thought to be not too severe.

It is likely that system users will request, some time soon after deployment, that these reminders be scaled back, and if the capability to do so has not been built into the project, to turn them off altogether. This thereby loses the value of that particular automation. So, where am I going with all this? While workflows can be redeployed without a major release, it is unlikely most Siebel project teams are actually prepared to do so on short notice. It is possible to account for this by explicitly adding requirements for it, but of course this adds complexity and scope to the project.

This is all why I built the RARE Engine to be extensively customizable in the GUI, including the turning on and off of email reminders, the setting of the text of the reminder/escalation message, and the delay interval between reminders and escalations both on a per person and per process basis. This means that after the process has been automated and deployed, an administrator can tweak these parameters to the individual needs of the user base.