Let us go back to the order-entry example and its (single) business objective of reducing the time taken to enter error-free orders. We had developed a partial list of actions for assuring performance with regard to this objective, on two separate threads:
Business Execution thread:
– owner: customer, action: train end-users on orders and their entry.
– owner: customer, action: take up some process reengineering and rationalizing.
– owner: customer, action: make available end-users for training.
– owner: customer, action: adequate bandwidth to be provided to connect up with the back-end order-entry system.
IT Execution thread:
– owner: software service provider, action: train end-users on the new solution.
– owner: software service provide, action: design lightly loaded screens, minimize server visits…
– owner: software service provider, action: make the screens intuitively obvious, minimize clicks for main flow, use technologies like Ajax for rich user interface, generate meaningful error messages, provide useful defaults, drop-down selects, auto-fill, etc. to reduce data entry effort.
– owner: software service provider, action: include in requirements and design the feature to save a partially filled order; also it should be possible for another authorized user to later complete the partially filled order.
The customer’s organization owns the Business Execution thread while the IT Execution thread is driven by the service provider. In this example, there are only two broad organization-level ownerships shown. In general, there could be more specific roles, drawn from the stakeholders and their organizational structures.
Also, the actions read generic in the above. In real, they could get quite context specific in terms of the intents and measures (see examples below).
Some of the actions directly map as activities of a project plan. Example: training end-users on the new solution. And, some could go under SDLC guidelines for the project, gross or fine-grained. Examples: [A design guideline: the landing page should not exceed 60 kb]; [A feature-level coding standard: stored procedures handling multiple on-screen selections should use of table variables for simplicity and speed (this is fine-grained)].
Now, the guidelines strongly emanate from business objectives instead of degenerating into a huge ‘cut and pasted’ linear list. Even if the guidelines are already in place and not generated in this manner, it would still be useful to validate them along these lines to fill the gaps and weed out the unimportant. For instance, it may show that certain business-level failure syndromes may not have sufficient guidelines to protect – a gap to be plugged. It may also be possible to apply a sense of priority to the set of SDLC standards which always threaten to get prolific and often in mutual conflict.
Incidentally, an earlier post ‘Coding Standards – a chimera?’ spoke of the importance of relating the coding standards to architectural attributes and other keys. Here we are enlarging it to relate all SDLC standards as strongly as possible to business objectives which in turn form the basis for the said architectural attributes.
Preemptive planning of this kind significantly enhances assurance of achieving intended business objectives.
In summary, the submission made here is to recognize and plan in a Business Execution thread in mesh with the IT Execution thread which usually is all of a conventional project plan. This stems from conceiving a project to include the main purpose of achieving business objectives instead of limiting it to software deliverables as is the current practice. With it, the clear statement that business objectives have a greater chance of being realized only if both the customer and the service provider plan and work together from day one with an end-to-end vision. On this road, the SDLC standards stand out with definite prioritized purpose.
Extending the scope of a project beyond the limits of software deliverables is an opportunity for the service provider to provide tangible business value, fraught with interesting possibilities for ongoing engagement with the customer. If ERP roll-outs are planned and executed along these lines (not the whole nine yards yet), why not bespoke development?