Insourcing for IT organizations

Most IT organizations are structured to becomes a monopoly within the firm and like monopolies are wont to do, they start taking their position for granted. They become large, expensive and slow in response to their customers i.e. the business. Arguably, this hurts the firm’s competitiveness in a big way.

David Rasmussen in Cutter advisor argues that IT organizations should be competing for providing the services like any other firms within a competitive environment . They also need to make the mind shift from speaking techno geek to business speak. He challenges the IT executives to define their value add in terms of EPS to earn the right of being the preferred supplier.

I agree wholeheartedly with this philosophy. What’s not mentioned in the article though is how to break the barriers to entry that IT creates. Often, the business rely upon IT to also make decisions about sourcing from other vendors. This is akin to asking your wife to select a girfriend for you (okay bad metaphor – but you get the point). Other times, the IT still remains in the equation through the backdoor of security and hardware provisioning. IT sometimes also create virtual organizations who act as conduit between business and the external service provider, creating communication barriers.

Business, ultimately, are left no better than where they started from. The competitive environment has to be equal for all participants, for the customer to be better off. What is needed is an ombudsman who can arbitrate on such matters and protect the customer’s rights to earn their value.

Stakeholder value and not business value

The classical view of a firm has been that is a profit maximising organization operated by professional managers on behalf of the shareholders.All the activities of the professional managers on behalf of the firm are geared towards maximising the shareholder value.

A more balanced view is that a firm is more than simply a financial vehicle and has more constituents than shareholders alone.A firm combines the interests of customers, employers and suppliers, all of whom contribute to the firm’s success. This approach is known as “stakeholder approach” and makes the firm’s managers accountable to a wider community than just the shareholders.

In Agile, the approach has been to establish and validate the “business value” of a project and its constituent stories for efficient prioritisation. This has often led to the confusion amongst project team members. The connotation “Business Value” establishes an unnecessary connection with “Business” i.e. the project sponsors, inadvertently leading to prioritising functional stories over non-functional stories.

One approach to solve this problem has been to demonstrate that even non-functional stories have “business value”. For example,it is possible to show that “Logging” allows the Application support team to spend lesser time on defect analysis, thereby reducing the turnaround time for the defect. “Business” would therefore be in a position to prioritise such a technical story as well.

Whilst this approach has been successful, it fails to achieve the mind shift that is required to make it happen consistently. There is a wider community out there which will determine the success of the project such as the project team members, the application users, the support team members etc. All of these are stakeholders who have an interest in how the project shapes up and should rightfully, be involved within any prioritisation exercise.

Only when we start looking for “Stakeholder Value”, will we ensure that the wider community is not forgotten. The term “Business Value” needs to be consigned to history.

My colleague,Marc, has gone a step further and suggests associating drivers for each stakeholder to achieve the same result.

False Economy

Blackburn Rovers finished 6th in the Premier League in 2002-2003. At the end of the season, they sold Damien Duff, their main attacking threat, to Chelsea for £17.5 mn. Sounds like a good deal, right ?

Subsequent season, Rovers finished 15th. They lost the income they would have received by participating in the UEFA cup and also, lost the merit television revenues that are determined by the position on the table. Approx £10mn lost in UEFA cup revenues and nearly £3 mn lost due to position on the table. £13 mn wiped off the £17.5 mn gained from selling their key player. The deal does not look good anymore, does it ? Clearly in football,selling your key assets is not a good strategy.

However, too often people use false economy to justify a short term gain and soon, such decision comes to bite them where it hurts the most.

What does this have to do with IT ? Well, the laws of economics apply everywhere. So many organisations still treat IT as an unwanted child and outsource them. IT function is viewed as non-core and hence, an ideal candidate to be outsourced too.
Big consultancies provide a flashy business case that demonstrates “great savings” to the purchasing organization while taking away their painful headache. Too good to be true, n’est ce pas ?

The truth is that nearly 2/3rds of the outsourcing deals have failed/ are failing. Sainsbury’s has recently written off £290mn it had invested in an outsourced deal to Accenture. Over the years of this outsourced deal, they have also lost ground to Asda and Tesco. Coincidence ? Methinks not.

In today’s environment, IT is/should be the strategic arm for most organizations . Outsourcing it in the name of “cost savings” and “non core competency” will prove to be false economy.

Big Bang Production release

A lot has been said about how early and frequent releases allow business users to start using the system faster and thereby, earning a higher ROI. Conceptually this is true and can be proven through the NPV formula which takes the time value of money into account. Practically speaking, a system is sometimes not actually useful in parts. This is especially true of websites on public domain. They need to have evolved in both functionality and usability before they see the light of the day. There are implications on company positioning and branding if a cut down version either in functionality or usability is presented to the whole wide world.

So does this mean that a waterfall methodology will provide the same ROI where there is a need for a big bang production release ? ROI calculation of the system based on only the productive use of the system ignores the other benefits associated with short frequent releases such as
1. Delivery risks are lowered
2. Activities like focus group interviews, user training, testing etc. can be parallelised
3. Developers can remain focussed.

It should be possible to quantify these benefits and demonstrate that the ROI can be achieved irrespective of when the system is put into production.

Crossing the Chasm

I often hear people complain that Agile is not yet mainstream and hence, not been adopted widely.Ignore the obvious circular reference for the moment. Lets compare Agile practices adoption with a similar revolutionary principles applied to the manufacturing discipline – Toyota Production Systems.

The Agile Manifesto came out in 2001. Assuming that the practitioners were using it at least 5 years before in varied shapes and forms, it implies it has only been around for the last 10 years or so.

TPS was first instituted in Toyota in the late 1940s. However, no one really noticed it until the oil crisis hit the world in 1973.Toyota was able to sustain the earnings in the subsequent years . From this point onwards, Japanese manufactures began adopting it and subsequently, the world. It was from this point onwards that lean manufacturing principles became mainstream.

The oil crisis was the inflexion point which made the world sit up and notice the success of lean manufacturing.A similar inflexion point will do for Agile what oil crisis did for the lean manufacturing. Catastrophes like NHS and Sainsbury’s IT projects have already highlighted the deepening crisis with formal methodologies. For all you know… its just around the corner..

Analysts should think like entrepreneurs

Every business has a simple model to begin with. An entrepreneur, while setting up a new business, would normally follow the steps listed below

  1. Assess the need for the service/product
  2. Determine whether it needs to be greenfield development or can be purchased outright
  3. Start with the lowest initial outlay possible for the business
  4. Gather customer feedback
  5. Identify improvements to service/products
  6. Implement and test the improvement
  7. Go back to step 4

An Agile analyst should think like an entrepreneur for the system that they are building. The same set of steps apply again

  1. Assess the need for service/product
  2. Determine whether the product/service can be bought or built
  3. Start with the simplest model of the system
  4. Showcase
  5. Identify incremental requirements
  6. Implement and test the requirements
  7. Go back to step 4

Will the real customer please stand up?

One of the prime requirements for the success of Agile Projects is to have an “onsite customer“. In reality the real customers rarely have either the time and often, the inclination to be involved with the development team on a full time basis. After all, there is a business that needs to be attended – things dont come to a standstill while the system is being developed. The accepted wisdom is to have business analysts serve as “proxy customers“, thereby leveraging the real customers’ time. Business analysts are presumed to have the necessary skills and experience to drive out the project requirements by having sessions with the real customer and therefore, be in the position to make the best decision for the project. So far so good.

Unfortunately,there is an additional layer that gets introduced within the fray.The real customer is often hands off, and a token customer is assigned to liaise with the business analyst. This is typically a junior member within the user community or a business analyst / domain expert working for the client.This person might have the knowledge of the functional area for the system, however they usually do not have the same level of authority and big picture outlook that the real customer does.

The risk of not having an onsite customer has now been replaced with a different type of risk – Risk of having a token customer. Listed below are some of its possible implications

1. The token customer’s future career / bonus is usually contingent on the mandated success of this project. Conventional wisdom about a successful project is the delivery of agreed functionality on time, on schedule and to the agreed resources. Usually such mandates are taken too literally and as a result, any form of negotiation is viewed as compromise.
2. Productivity of the team is assumed at the beginning of the project and subsequently, calibrated over a period of time during the iterations depending on the team’s performance. This may mean changes required either in scope, time or resources and usually, our token customer is not the best equipped to make the decision.
3. The token customer may have previous experience with developing a similar system and this could result in typical analysis anti-patterns such as “Re-inventing the wheel”,”Re-inventing the square wheel”, “Golden Hammer” etc. Scope creeps can occur as the token customer may try to shoehorn some requirements within the existing story list.
4. Difficult to establish the business case for the system as the token customer may not necessarily have the complete knowledge of the drivers.

Here are some of the mitigation strategies that have been tried before
1. Involve the real customer as much as possible, especially where key decisions need to be made. Showcases, iteration planning meetings, kickoffs etc. are ideal candidates for the customer involvement. Ensure that the meetings are short and therefore, would not tax the schedule of the customer heavily.
2.The success criteria for the project should get defined jointly between the team and the customer. This ensures that the mandate given to the token customer is aligned to the development team’s delivery commitment.
3. Educate the token customer on their roles and responsibilities within an Agile project. Give examples of different scenarios that occur within an agile project and the different decision points. Ensure that the escalation points are identified as well.
4. Manage the scope at story level tightly. By documenting all key assumptions made during the story identification, estimation and detailing, the BA will have the right arguments to make when negotiating with our token customer.
5. Structure the engagement to have a senior member of the development team emerge as a trusted advisor to the client.This senior member should be able to coach the real customers/ sponsors to identify the business value within the requirements.