A software service provider (applies to internal IT too) usually evaluates his own performance in regard to his customer’s projects on costs, effort and timeline. A project is considered successfully completed if the targets are met on these metrics. While a project may be successfully completed and deployed, it may not still achieve end-to-end business objectives set out initially by the project sponsor in the business case, for various reasons. The one reason is that often the service provider only sees the requirements detailed out to him and not the business objectives themselves. Could the project be planned more holistically if the service provider is exposed to the business objectives as well? Let us see how this could be done.
For example, consider the business objective: the time taken to enter an error-free customer order into the system needs to be reduced (metrics omitted).
For assuring performance in regard to this objective, it is translated into a set of actions necessary on part of the stakeholders. These actions could be developed using any method. Here, we imagine the contrary, examine reasons and develop preemptive actions.
Continuing with the above example of order-entry, the business objective of reducing the time taken to enter error-free orders may not successful because of one or more of the following reasons (alongside, a possible preemptive action to protect against this cause of failure is indicated and its ownership):
– The end-users (customer’s order-entry personnel) are not familiar with the business aspects of a customer-order especially about the changes from earlier practices (owner: customer, action: train end-users on orders and their entry).
– The types of customer-orders and their entry are too various and difficult to comprehend (owner: customer. action: take up some process reengineering and rationalizing; however, much of it could lie outside the scope in the current context of developing a software solution for order-entry).
– The end-users are not trained on effectively using this software (owner: software service provider, action: train end-users on the new solution; owner: customer, action: make available end-users for training).
– The system is sluggish in its responses when an order is entered (owner: customer, action: provide adequate bandwidth to connect up with the back-end order-entry system; owner: software service provide, action: design lightly loaded screens, minimize server visits…)
– The users have to do more work to get an order entered into the system (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 defaults to reduce data entry effort…).
– If the order-entry is interrupted for some reason, user has to start all over again (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 above list though not all-inclusive is sufficient for making the point.
Realization of business objectives in a project could be viewed as a combination of ‘Business Execution’ and ‘IT Execution’ threads. Actions such as rationalizing order types and their processing, training the end-users, etc. come under Business Execution thread while actions of SDLC and infrastructure kinds go under IT Execution.
Now the point being made is: a unified project plan must include actions from both the threads for assurance on the achievement of the business objectives, and their synchronization. Even though it is still only an assurance and not a guarantee for results, this holistic approach is likely to yield better end-to-end results. This is in sharp contrast to the current practice wherein the Business Execution thread is at best a diffused set of activities and ownership, and not tightly managed. And the business objectives are not very visible to the service provider.
It is not as if the all actions in Business Execution thread are owned by the customer and similarly all actions in IT Execution thread, by the service provider. Example: owner: customer, action: provide adequate bandwidth to connect up with the back-end order-entry system goes under IT Execution thread as mentioned earlier.
It would be nice if the planning tool allows the threads to be managed individually and collectively in a composite plan with all interdependencies coded.
Who manages the Business Execution thread? A simple straightforward answer is a manager designated by the sponsor in customer organization. Depending on the kind of activities on this thread, other variations are possible. In simple cases, the service provider’s project manager could assume overall responsibility, keeping in mind that the project management competency is what he brings to the table. Even now he manages actions that call for heavy participation of the customer: scope management, change management, risk management, knowledge transfer, testing and approving deliverables. This enhanced responsibility is clearly an opportunity for the customer to derive more value from the service provider and for the service provider to differentiate his services.
Regardless of who manages it, the Business Execution thread is recognized for what it is, planned and meshed with the IT Execution thread.
On the side of the business, it is no longer the traditional role of someone acting merely as the single-point contact for the service provider. It is a more demanding role of one who manages an important thread of actions in the project.
(More to follow)