External, visible effects of using VPEC-T

Values is a flexible label that encompasses any benefit that any party using or delivering the Information System expects to receive from it.  First and foremost, ‘values’ will relate to the business goals, but also included may be general principles that the business follows, departmental objectives and individuals' motives.  This last item, in my experience, has more influence on the success of information systems than might be expected.  Understanding what makes the individuals involved tick will help in judging motives and bring a new note of reality to considering the right approach to implementation, once the VPEC-T study has been done.

Values to the business will be described in the VPEC-T deliverables, value to individuals may or may not be, depending on the circumstances.  Whatever is found concerning values to individuals that affect the information system may need to be taken into account discretely, but may not always be appropriate to write up in the main report.

The rules that the system must adhere to are known well before rigorous design or evaluation of technological solutions begins.   At this stage, it should also be possible to identify if conflicts exist between Policies.

The VPEC-T deliverables will state Policies affecting the information system, either explicitly or by reference to an authoritative source of this information.

They will also state potential policy conflicts identified and, if determined at this stage, possible ways to resolve these conflicts.

Events are triggers for specific streams of business activity.  Without the event, the activity will not start.  Events may arise from a contact by a customer, passing a milestone, a change in something that's important to the business.

Some examples: a web server receiving an on-line order from a customer is an Event, the same server receiving authorization from a credit card company is another, the Fulfillment Department handing the ordered item to a courier is an Event, and the receipt of notification from a credit card company that a customer has disputed a charge is another.

Events may have internal actors (credit check officer, say) or external ones (for example, a customer).  They may be a prescribed Events, something like “beginning on the first working day after 15th of each month we have to check the status of....”.  In that case it will be an Event caused by a Policy.

Business systems analysts have long used events as an entry into a new area that is the subject of a feasibility study or system requirements gathering exercise.  They could hardly avoid it - business users think in terms of events: “When the order come in I have to check its contents for completeness and accuracy of parts number and customer address.  Then I check the customer's credit status, and if that's OK, I verify the stock levels.” The business user probably thinks of that as one event (order arrives). But buried in it could be many implied events: Overseas order arrives; local order arrives; customer credit check bad; stock level too low to fulfill order; item no longer sold; ...

What is new in VPEC-T is not that practitioners listen to descriptions of events, observe them, write them up, and so on.  What's new is the treatment of Events as a whole stratum of information describing how a business works.  Separating them initially from the information collected and processed, and especially separating Events from the business process keeps the focus on what must be done and avoids it slipping into “how do you do that?” at too early a stage.

The VPEC-T deliverables will list each Event, cross-referenced to Content used by the business activity the Event triggers, or generated by the activity.  It will also show Policies controlling that specific business activity.

Content in VPEC-T is made up of much more than just data. All IT people do data after all - endlessly - we have to.  But is something missing? Here, Content is taken to include documents, messages, even conversations, provided they contribute to the business outcome, as well as data held formally in databases, and other structured computer files.

It is often the case that the technology is considered too early - some parties involved may be pushing a specific solution even before the business outcomes are fully understood. As a result, formal definitions of data will be considered early on, while information that doesn't fit, especially if it is informal, is pushed to one side and neglected.

There are many aspects of communication - the communication channel; the medium; the originator; the recipient.  But VPEC-T seeks to have information about Content collected in all cases and placed in the business context.

The VPEC-T deliverables will list each item of Content, cross-referenced to the Events in which it is used and Policies constraining data in that Content.

Business analysts using VPEC-T will be primed to spot areas where Trust is missing and address them.  Yes, let's recognize, as VPEC-T does, that negative thinking is not helpful and avoid the word ‘mistrust’.  Opportunities to build Trust are actively sought out, identified and discussed.

This means that the business and IT providers both come to recognize Trust as critical ... something that can affect the final success of an information system ... something that must be nurtured actively.

Even in cases where Trust is not an issue, it will be given the focus at various stages, as the VPEC-T study proceeds.  This improves the chances of spotting where a Trusting relationship could be at risk if the circumstances change.

The VPEC-T deliverables are unlikely to list Trust matters unless they have been impossible to resolve and appear to be a threat to the success of the project.  Then involvement by the project sponsor (or above) will be needed.