Modern organizations work in a large horizontal and vertical network comprising of entities who interact [pass information or material or capital] with each other. Optimizing one relationship without considering the effect of the same on the overall system, can lead to lower and sub-optimal business value. One example of such a sub-optimal step includes stocking vast piles of inventory leading to massive increase in storage costs and loss of stored material, where considering this entity from a systems thinking perspective led to growth of Just in Time Inventory Control. “Outsource to cheap vendor” is one such sub-optimal step an organization could take. Cutting costs is a useful goal for an organization to focus on but is probably not the only goal the organization should focus on. Other goals to focus on could generally include quality, faster time to market, responsiveness to change, flexibility, competitive advantage. While deciding to outsource work, an organization would want the business value to be optimized across the value chain rather than just cut costs.

However, optimizing business value across a value chain, a difficult goal even if all work is done in a single organization, is especially difficult when the value chain includes more than one organization [which is the case when you outsource]. Generally, within the organization, each department is trying to maximize its own individual measurements. This gets magnified within an outsourcing environment where each organization is trying to extract the maximum pound of flesh from the deal as possible. The pound of flesh is generally defined and tracked by individual measurements in each organization. For instance, the firm outsourcing the work negotiates on the lowest price possible while the vendor is typically looking to not exceed the price while developing the project. As is obvious, these measurements do not span the value chain and will invariably [particularly if the products are critical, large or in demand] cause sub-optimized business value across the organizations. In the above example, none of the two organizations is actually focusing on “getting the right product to the market in the right time” and the “overall business value” has not been defined specifically. Rather, a contractual document with clauses and clauses to define the “terms of engagement” is generally put in place between two companies. The immediate fall out of contracts is to cause measurements and controls such as cost, schedule and scope. It is also assumed that meeting the contract terms is equivalent to providing business value. This is often misguided thinking. A collaboration is successful if it provides something useful and not because it delivered something thats “within scope, within cost and on time”. Cost and time are important parameters but already considered within “something useful” [something spiraling out of cost or time would rarely be useful]. Hence, cost - schedule - scope triangle does not define business value. Rather, such measurement will mostly get in the way of driving the effort toward true business value. The fundamental focus should be to do away with sub-optimizing points of measurement so as to optimize business value across multiple companies.

If cost, scope and time do not define business value - then it is logical to ask what would. In software, we generally consider value to be defined as function of features, quality, time and cost. Within this paradigm, it has to be noted that true business value would be more dependent on features and quality, and often not on meeting *tight* deadlines and rarely on meeting *tight* cost targets. The distinction between deadlines and costs being “exceeded by a distance” and “not being met” is subtle but important. The most important aspect in the business value as per the parameters above are the features. Features embody “what is being built“, “what is the business case“, “risk associated in not developing” etc. Sometimes, there would be a risk for not “doing by a date” and very often for “not being up to mark on the quality“. The fact that we keep features, quality, time and cost as parameters reflects their dynamic nature. These change because:

• What was thought nice to develop today, might be outdated or too risky tomorrow
• What was the priority today might not be a priority tomorrow
• Some new features might be discovered
• Some new standards of quality might need to be adhered to
• Timelines might be important today but not tomorrow
• We might have cost surplus today but not tomorrow

Based on the above, another dimension needs to be added to define business value in these dynamic times. We can call it “flexibility” or “responsiveness to change“.

Hence, business value at its very least for today’s “terms of engagement” has to focus as a function of features, quality, time, cost and flexibility. Most Scrum teams [and Agile teams as well] pride themselves in delivering business value faster and regularly. Business Value operates at multiple levels through simple means in Scrum. For instance, prioritized backlog allows delivery of high priority features first. Product Owners usually decide the priority by balancing risk and opportunity. Focusing on risk allows early feedback and course correction. This reduces the risk of developing wrong features or wrong product itself. The development people [which could be outsourced offshore] and the business people work as one team on prioritized features. Further, the measurement for business side is on prioritizing the features to be developed and explain business case and acceptance criteria along with evaluating/ providing feedback on developed features. The measurement for development side is to develop highest priority features and incorporate change. In addition, the review of the priorities and work done as per the priorities is held at the end of each iteration, which is usually only a few weeks. Ruthless prioritization of the features to be developed along with a strong inspection and adaptation framework creates a flexible, self correcting and highly transparent mechanism for engagement between both sides.

Popularity: 47%

Posted on December 28th, 2007 by admin
Filed under: Business Alignment, Collaboration, Outsourcing 2.0 | No Comments »