jump to navigation

Business Processes: Configuration, Customization and Convergence November 27, 2012

Posted by Tim Rodgers in Management & leadership, Organizational dynamics, Process engineering.
Tags: , , , ,
trackback

In the mid-00s after Mark Hurd’s accession to the CEO office HP’s senior leadership aggressively pursued overhead cost reduction to improve the firm’s profitability. HP’s CIO used this opportunity to consolidate IT functions, simplify processes, and eliminate redundancies due in-part to “shadow IT” groups that had grown up during the previous era of independent business units and local autonomy.

One of the early targets were the defect tracking systems used by product development teams for reporting, management, and disposition of defects found during pre-release testing. I don’t remember the exact count, but apparently the number of active defect tracking systems was in double figures. The IT team determined that convergence on a single, common, corporate-wide DTS hosted on corporate servers would lead to significant savings: from reduced headcount and other support resources, and harder-to-quantify efficiency, productivity and communication improvements.

The DTS convergence project did not go smoothly. Many product development teams objected strongly to the plan. They claimed that they would not be able to meet schedule and quality commitments for projects already in-progress if they were forced to switch to a different DTS in mid-stream. Unfortunately it didn’t help that the corporate IT team seriously underestimated the effort required to manage the transitions. Some product development teams appealed to their business unit executive, looking for an exemption or at least a delay. Others adopted a passive-aggressive position that only hardened the resolve of the IT team.

The corporate IT team objected strongly to the idea of local customization of the DTS and supporting processes, arguing that the overall cost savings and other benefits would be significantly reduced if every product development team were allowed to run their own system. I think the IT folks would have had a better chance of success if they had acknowledged the value of local solutions and introduced a system that enabled local configuration instead of customization. 

The core functionality of the DTS could be retained, and the support resources minimized, while allowing the local product development team to define or select options to match their familiar and preferred style. Certainly this would not have eliminated all resistance to the change, but it would have enabled a more balanced discussion of the benefits of a common DTS that recognizes and values the needs of product development.

This happens frequently in business processes of all kinds, especially in multi-site organizations or in the aftermath of a merger/acquisition . One side pushes for convergence and the other side insists that they need a custom solution because of their unique requirements. The trick is to find a way to design a common system that can be locally configured without giving up the expected benefits in support cost and communication.

Advertisements

Comments»

No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: