More on the actions that go into Business Execution and IT Execution threads and some new opportunities for service providers:
In a typical ERP roll-out, most actions go into the Business Execution (BE) thread. There would be actions in the IT Execution (ITE) thread to install, configure and customize the solution. But these actions are driven by actions in the BE thread.
Should that not also be the case with non-ERP solution development and roll out? Since the solution is being developed and is not ready off the shelf, that happens to be an intensive set of SDLC actions. Nevertheless the interlock with the BE thread must be maximized so that course corrections if any are applied at the earliest point of time. Obviously these interlocks must be purposefully arranged for productive use of the customer’s time and not be contrived.
There is this famous curve usually produced often in project kick-off meetings which shows the actions on part of the customer and the developer in a typical SDLC project, without formally identifying the two threads as we have done. The customer involvement peaks initially during requirement gathering phase, drops off during the design and coding phases and again perks up during the acceptance testing phase. This is more the case in waterfall execution and can be adapted suitably for other paradigms of development as well.
The traditional SDLC model does not stretch itself (while ERP roll-outs may) to cover successful roll-outs. This is a crucial activity and the solution developed morphs into shelf-ware if the roll-out is not handled with professional competence and precision.
There is an even more important question of whether the business objectives of the project as originally conceived by its sponsor are achieved thru the usage of this solution. This immediately implies a period of usage on part of the end-users after the roll-out.
The ERP world makes a weak attempt by way of a post-implementation audit service, while the traditional SDLC model completely disassociates with this question. So, between the roll-out and the audit, who is concerned with the progress made? Can it be left to the customer to drive this march without any inputs of professional expertise? What are those sign-posts for success and the failure syndromes? Shouldn’t there be a well-planned and sustained effort during this critical phase? Note this is different from the L1-L2-L3-L4 support of Application Management Services.
The plea made here is: this is a definite opportunity for the service provider to enlarge his bouquet of services and value he delivers to cover these milestones and the customer has some reassurance towards achieving the intended benefits.
Some mature customers even now do plan end-to-end and arrange for themselves assistance of this kind either from the service provider or from some other agency. In any case there seems to be a clear need for formally structuring the actions and defining the services and deliverables associated with the two milestones. And plan them in from the ‘go’. This can also lead to some risk-reward models for the service provider, once these services mature.
(More to follow)