CONTRACTING FOR CAPABILITY: the future of outsourcing Reply

Outsourcing only works for vendors. It does not work for customers. Revenue curves for vendors show a slight increase since 2008 for global outsourcing growth but the picture is less clear for customers. When looking at the economic-value-added (EVA) for businesses before and after outsourcing deals most show a nett decrease, which is to say only that they are weaker after the deal but not necessarily because of it.

The reasons are myriad however there are a few standard reasons:

  1. outsourcing is usually part of cost reduction activities of panicking organisations.
  2. there is usually a nett decrease in headcount which wipes out the value-added aspects of reduced costs.
  3. the customer’s SG&A costs usually rise due to the increased management activity needed in finding and using information.

Due to these reasons there is a feeling in the market that outsourcing does not work despite the claims of vendors. Therefore, vendors have increasingly (certainly since 2007) seen themselves fighting for an ever shrinking slice of the economic pie. The greatest sources of competitive advantage have been reputations and economies of scale. All, however, have been scrambling for a differentiator that does not involve reducing their own profits.

MIDDLE-OFFICE OUTSOURCING

One large UK outsourcing outfit saw the writing on the wall. It felt that it would not be able to compete with the lower labour (and similar outputs) of India-based companies. It rationalised that eventually it would be squeezed out of the back-office (i.e. highly standardised financial processes) outsourcing and infrastructure hosting markets. It would, it rationalised, need to move into middle-office outsourcing. Front-office outsourcing, on the other hand, is largely fictional as it encompasses the customer-facing aspects of a business which is where the key differentiators are.

Middle-office outsourcing (such as a council planning approvals process) is unique because it involves less repetitive processes and sometimes ad hoc activities.  Success here is necessarily predicated on a flexible IT infrastructures (often service-based, i.e. SOA) and a sophisticated management which is able to choreograph technology-based processes and services.

COMMERCIAL CAPABILITIES

Being able to outsource the middle-office involves positioning the vendor into a customer’s capability. A capability is the ensemble of systems, processes, people and information/data necessary to do something. In business terms this means all the stuff that is necessary to perform a process. Technically, capabilities are specifications of an enterprise’s Value Chain, so in broad terms a business will have about 20-ish key capabilities. All capabilities are, necessarily, linked. The closer one gets to the front-office the more these capabilities need to (i) be performed and supported in real-time, and (ii) they also need to consume information and services from elsewhere in the business. For instance, in our planning approvals process example the vendor will have to (a) log approvals in real-time, (b) consume up to date information on structures and utilities, as well as (c) access information on business rules (i.e. council policy, governance, law etc). As with any outsourcing activity, more narrowly focused personnel on lower pay bands are used to perform tasks more ably supported by better technology. All these aspects not only add to the complexity (and therefore the price) but also to the potential liability. When offering low pay band workers to crank the handle on repetitive processes liability is something a vendor wishes assiduously to avoid.

DEFENCE CAPABILITIES

Capability is a term much abused but little understood in Defence circles. Much of this is because Defence does not use a standard value chain. Although there is a business model for most western Defence communities (Inform > Project > Operate etc) there is no need for a value chain because there is (i) no need to differentiate, and (ii) planning and financing is based on the use of ‘unlimited’ funds to confront external threats (i.e. Treasury tends to play second fiddle during war).

The military user will often class themselves as a ‘special’ customer. The defence industrial complex is a special environment for the simple reason that they are providing equipment which – if the enemy is successful – is useless to the customer by the time it enters service. Unlike the commercial enterprise, where such a situation would mean they lost some competitive advantage/margin, in the military such a situation is untenable. The purpose of a military capability is therefore to change quickly and radically over time in line with the threat. Corporate structures are notoriously incapable of maintaining the same tempo of development, even with lavish operational funding. The purpose of ‘Contracting for Capability’ is to solve the problem of commercial-lag whilst still providing a cost effective and commercially robust means of contracting.

THE CONTRACT: A COMPLEX ADAPTIVE SYSTEM

This is possible by viewing the capability environment as a complex evolving system which requires the commercial deal to be a complex adaptive system. This is not new to the law. Building and construction deals have been taking this approach for years and German franchising law has excellent precedents showing how risk may be judicially assessed throughout a large, distributed network of commercial entities – for a common purpose or effect.

Figure 1 – Shows how commercial deals fail to keep pace with and support military capabilities.

‘ROLES’ – The Key to Capability

The key difference between commercial and military capability is that in the military environment the vendor cannot own the people. In business, the customer will transfer the roles over to the vendor. In the military equivalents of the middle and front offices (i.e. front line and forward echelons) the vendor will never own the people. Soldiers will always perform critical tasks. This will remain a constant for some time to come as soldiers do not say (i) “the computer isn’t working”, or (ii) “do I get overtime?” etc.

Although a vendor cannot own the people it can own the ‘Role’ or the role specification, i.e. the processes, information and systems that a role uses. In this way, a vendor can support the core functions of a role without hindering the actual person’s ability to go outside the boundaries of that specification to ensure that something is done. For instance, a aeromedical evacuation must take place regardless of whether a computer is not working. The airman performing the tasking may have at their disposal a sophisticated orchestration of processes based on flight availabilities, supporting gunships, bed availability and surgeons on duty. However, if the network is down it is unacceptable to let a soldier die just because the computers are not working. That airman must now use their deep knowledge to work the radios and help save a life. On the other hand the military is largely incapable (and unwilling) to integrate the vast array of ICT necessary to develop the initial systems.

Figure 2 – ‘Contracting for Capability’ using commercial communities to support capability clusters.

COMPLEX CAPABILITY

The example of an aeromed evacuation is somewhat simplistic. The example above refers to the Deep Target Attack capability. This capability may be performed by submarine/ship-launched missile strike, aircraft or even Special Forces. The choice is a military judgement. In the case of a submarine launched method the enemy will try to prevent this through anti-submarine naval activity (ASW). The submarine needs to close to striking distance, reach launch depth and then withdraw safely. How is it possible to support such a process which involves very long and expensive R&D lead times, long into-service acceptance testing, new training and tight export controls as well as restrictions on the use and sharing of sensitive information?

The trick is to incentivise the commercial community to do some of the thinking for the military. Instead of having to wade through the commercial treacle of Defence procurement the following steps could be taken:

  1. Base contracts on Capability Increments. In this way, the vendor is obliged to keep pace with threat evolution and the development of capabilities.
  2. Outsource the Role Specification. This will ensure that the military community is forced to involve its commercial delivery partners (without being hamstrung by systems).
  3. Create Commercial Communities around the support to certain key systems/clusters of technology. This is similar to German franchise systems whereby all parties are legally obliged to discharge their contractual obligations in line with a common purpose. This will circumvent the horrific impasses usually experienced in alliance contracts.

Contracting For Capability is a logically sensible concept which simply builds upon the work already achieved in the Enterprise Architecture community (especially MoDAF, MoDEM and the IDEAS Group). It is not overly complex nor is it a step too far. Once again, the real question is whether Defence and industry have the sophistication and diligence to complete the task.

McKinsey – Why the Customer pays for Risk Reply

In the forthcoming McKinsey Insights article “Avoiding Blindspots in Your Next Joint Venture” the authors point out some of their recent research into the failure of JVs. Further to my previous post about the need to design accurate risk models into a JV/Alliance/PPP, the authors note:

“At the beginning of any JV relationship, parent companies naturally have different risk profiles and appetites for risk, reflecting their unique backgrounds, experiences, and portfolios of initiatives, as well as their different exposures to market risk. Parent companies often neglect this aspect of planning, preferring to avoid conflict with their prospective partners and getting to mutually agreeable terms—even if those terms aren’t best for either the JV or its parents. But left unaddressed, such asymmetries often come to light during launch, expand once operations are under way, and ultimately can undermine the long-term success of the joint venture.

Certainly, some JVs must be rigidly defined to be effective and enforce the right behavior. But when that isn’t the case, JV planners too often leave contingency planning to the lawyers, focusing on legal protection and risk mitigation without the business sense, which shows up in the legalese of the arbitration process and exit provisions. Both tend to be adversarial processes that kick in after problems arise, when in fact contingency planning should just as often focus on the collaborative processes that anticipate changes and create mechanisms or agreements that enable parent companies to adapt with less dysfunction. As the head of strategy for one insurance company noted, “If a JV is set up correctly, particularly regarding governance and restructuring, it should be able to weather most storms between the parents.” Such mechanisms might include, for example, release valves in service-level agreements, partner-performance management, go/no-go triggers, or dynamic value-sharing arrangements and can allow a joint venture to maintain balance in spite of partners’ different or evolving priorities and risks.”

Designing proper risk models need not be adversarial. In the hands of a skilled lawyer or commercial manager it is a sharp and powerful weapon at the negotiating table. This does not mean that the contract is not a win/win deal. On the contrary, insight into the proper and necessary allocation of risk is essential for a win/win deal. Anything else is simply wilful blindness. In fact, a more mathematical approach to risk modelling lays the foundation for a negotiating process that is more inquisitorial rather than adversarial. The primary questions remain: is the management sophisticated enough and does the business have the stomach for it?

The Customer Always Pays for Risk: risk allocation in large and complex contracts Reply

A recent report in The Australian (17/12/13) newspaper into the Air Warfare Destroyer (AWD) debacle states that the project is already $106M of its $618M budget for 2012-13 (a wastage of over $2M a week). The article states that the project delays are a combination of “shipbuilding bungles, infighting between partners, Defence budget cuts and a cultural clash with the ship’s Spanish designer, Navantia.” Poor efficiencies at the ASC in Adelaide and little coherence in the support phase are also contributing to the mess but the AWD Alliance still maintains it is on track because its emergency funds have not been exhausted.

The AWD Alliance is the “unwieldy and largely unaccountable” body responsible for the AWD project. The alliance is made up of ASC, the Defence Materiel Organisation and Raytheon Australia. The “secretive” alliance is apparently fractured by internal disputes, with the DMO blaming the ASC. The ASC, in turn, blames Navantia. Further still, the ASC is also blighted by a “poisonous” relationship with its primary subcontractor, BAE Systems.

This is a contracting issue:

  1. There is no issue with the Spanish design. This design was picked as part of a strict and comprehensive procurement process. If the ASC did not perform the requisite due diligence on the engineering then it should not be in the game of building ships.
  2. In multi-party construction contracts poor site efficiencies are largely a result of (i) cumbersome management, and (ii) poor depth of vision into the total supply chain. Both issues should have been obvious and ironed out at the contracting stage.
  3. There is no doubt that budget cuts and legislative change pose a high degree of risk. However, if the revenue curve of the corporate entities were subject to ill winds from Canberra then those teams did not do their jobs.
  4. Lastly, if a project is eating its emergency/contingency funds then it is an emergency and it is definitely not on track.

So, what’s wrong with Alliance contracting?

John Cooper, writing in the journal of Building & Construction Law (2009 25 BCL 372) notes that alliance contracting is increasingly popular in Australia. Promoted by contractors and adopted by some state governments it is seen as a way to overcome the problems said to be associated with “more traditional forms of contracting”. From this I assume he is including PPP contracts and their PFI/PF2 subset.

Alliance contracts are supposed to be more conducive to collegial management and better outcomes because:

  1. They are governed by a charter of principles and not the black letters of a strict contract.
  2. Each party (theoretically) operates in good faith (although, unlike German franchise law, not necessarily to the mutual benefit of the project).
  3. There is an understanding of “collective responsibility”
  4. There is a socially enforceable culture of “no-blame, no dispute”.

In fact, all of these points are patent nonsense and the article in The Australian and the Australian National Audit Office report on the same project clearly highlight the complete ineffectiveness of an Alliance contract in this instance.

At the heart of the problem is the risk model. Alliance contracts are popular for Defence because (i) the government underwrites the requirements risk (i.e. future requirements creep), and (ii) they do not have to expose this as an additional cost. So, the project appears to be good value for money. In fact, DMO is to blame here because it knows that it would never be able to get the AWD it wanted if it had to expose/pay for the risk. This is standard Defence sharp practice and to my mind borderline procurement fraud. By getting the government to underwrite the risk the DMO ends up getting the ship it wants at a bargain price. It ends up paying way over the odds but the project would never have been approved if the risk had been exposed. The price would simply have been too high.

In a standard construction contract the client would not underwrite future risk. So, the builder would cover this through (a) additional systems engineering to uncover and cost future dependencies, (b) they would insure against certain risks, and (c) they would then add this into the cost model, i.e. the customer would end up buying the risk back. In the end, the customer always pays for risk. Even if the builder has to absorb hefty liquidated damages for lateness the customer will still pay for them down the line in more aggressive management practices or exorbitant extension-of-time claims and even larger margins on acceleration costs. The customer always pays for risk.

NETWORK RISK

The primary cause of these problems is an unsophisticated and uneducated approach to contracting. Underlying these is the simple fact that risk cannot be allocated if the allocatee does not endorse the allocation. In fact, I would posit that risk cannot be allocated at all. Risk must be bought and sold in order for (i) a party to be truly incentivised to deal with risk, and (ii) the risk to go away. The last point is critical. In standard risk flow-down models risk never goes away. Rather, it simply flows down to the party with the least bargaining power to offload it. In the end, the customer always buys the risk back. In a network model, risk is sold to the party who wants it the most. In the end, they absorb the cost (or a certain percentage) based on the value they will reap in the event the risk is realised.

For instance, the network model below at Figure 1 is based on a large outsourcing contract. A multi-divisional outsourcing company won a contract to deliver products and services to a government body. Part of that contract was the hosting of IT infrastructure, a portal for public access and a billing application. The latter of which was being coded from scratch. In this model, the risk that the code for the billing application is held in escrow and the risk that the billing application will not be ready or fit for purpose (significant) is sold (i.e. the contingent risk) to another company in the model. In this way:

  • the purchaser of the risk get a (partially finished) billing application at a knock-down price (if the risk is realised).
  • the primary outsourcer can simply pass the application on to the former without having to find a suitable programmer in mid-flight, and therefore
  • the primary outsourcer does not need to insure this risk (so much), and
  • the original application company are greatly incentivised, lest they lose their R&D costs.

Additional vehicles (other than escrow) for contingent risk may be:

  • Step-In Rights
  • Holding other titles and licenses in escrow
  • contingent transfers of other property.

In all the cases something happens automatically. There is no better way to make this happen than for someone to profit from another’s poor performance. In such cases, the vampiric action of the vestee is swift justice for sub-standard management. When risk is realised, the vestee swoops and kills. There can be no greater motivation for either party. The primary question is whether a business has enough faith in its management to set up contracts in this way. Although a network model of risk is, technically, the best means to manage risk in large and complex contracts the businesses need to decide whether they have the management sophistication and the stomach to deal with risk in this way.

Figure 1 – Model of “Derived Risk” in a large outsourcing contract.

Give Me Back My Silo! The problems with cross-functional collaboration Reply

Collaboration requires trust.  Collaboration often requires risk with new relationships.  Collaboration requires doing something new.  In short, people do not like to collaborate.  People do not like to share.  People like safe relationships with others from the same educational background.  They collaborate with those who  share the same problem solving paradigms, issue identification and decision making criteria.  Knowledge and knowledge-intensive work is intensely hierarchical.  People guard their secrets and their weaknesses.  So, although the business may look towards de-layered flexible working structures as a cost saving measure, people do not necessarily follow.  Knowledge is and has always been a powerful means to embed and entrench power within an organisational hierarchy. 

Collaboration, however, is worth money.  In 1969 Peter Drucker noted that sharing and managing knowledge is “essential to organisational success” because it ensures sustainable competitive advantage.  How then do businesses best help employees engage and collaborate in a meaningful way which creates business value?quopte

Larry Prusak notes that large organisations performing complex tasks have been around since about 1860.  So far the corporate community has had over 160 years to solve this problem and we seem no nearer to it.  He posits that it seems so hard because, essentially, it is not possible.  There is no science behind it only heuristics.  Solutions are not algorithmic but rather anecdotally commonsensical.

quopte

The problem is that cross-functional collaboration is counter-intuitive.  It is not a normal feeling to share intra-discipline information with other functions around the business.  Complex ideas are not easily understood or translated outside professional groups.  Geologists and pharmacists can only explain an important discovery if it has immediately recognisable business value.  Lawyers can only explain the value of an idea if it averts imminent loss.  Manufacturers articulate the value of a process where it creates savings or improves revenue.  Everything else is esoteric gibberish. 

Thought leaders such as Prusak and Drucker well note that the answer to the standard problems of intra-disciplinary collaboration is to create well supported Communities-of-Practices (CoP).  Practices, they note, are best kept to about 200 members who meet about 2-3 times per year.  In the diagram below, such CoPs may extend beyond the walls of the organisation and may even include other competitors. 

To misquote Shoeless Joe Jackson in “Field of Dreams:  ‘Build it and they will not necessarily come.’  Increasing networks and their IT support will not necessarily produce any tangible return.  Most likely it will needlessly absorb organisational time and money only to increase the personal fiefdoms and create further bottlenecks and over-centralisation.  Such networks will help to increase the volume of knowledge within an organisation and problem solving but, critically, it will not help convert it it into business value.  In order to realise business value knowledge must cross functional boundaries.   

xFunctional Collaboration

GOVERNANCE & WORKFLOW

Knowledge will flow relatively freely within disciplines.  CoPs  address the problem of collaboration for such knowledge generation and problem solving.   Knowledge does, however, need to be forced across functional boundaries.  Commercial teams will not be drawn to good ideas.  They will not recognise them.  Workflows are essential to implement collaboration across organisational functions.  The key to implementing cross-functional (as opposed to hierarchical) workflows is to embed them in governance.  People will collaborate across functions if they cannot achieve their goals or get their work done.  The difficulty with any governance, however, is making sure that these ‘gates’ do not become bottlenecks.  Although the onus may be on the professions to present their work for approvals, so to is there a burden on the executive silos to understand and approve in a timely manner.  In this way there should be no burden on the operational disciplines to present their work on an ad hoc basis.  The presentational form must be agreed between professional and executive branches to understand.  There is no sense in letting commercial elements of the business dumb down sophisticated ideas.   Only when both parts of the organisation come together in mutual understanding is there truly any sense of collaboration across functions.

In the end trust will always trump value when it comes to the exchange of knowledge.   Indeed, businesses must actually increase organisational silos and insulate them rather than fight them.   The solution is not to break down the silos but to build them up.  People like safe relationships.  They like to feel warm and closeted from ‘outsiders’.  The key is to increase their sense of importance through revenue generating communities of practice in order to increase the volume of knowledge in an organisation.  Only then should the business increase the pace of converting knowledge to revenue through cross-functional workflows strictly embedded in the corporate governance.

PHANTOM RISKS: what to report in a risk register 2

phantomPhantom risks are, technically, unproven or unprovable facts which, if true, would pose as risks.  At the macro level they are an issue for western societies as they generally arise from poorly made scientific inferences which are hijacked and used to legislate pet projects.  Think of the religious right in the US trying to use scientific quackery to get creationism taught in schools.  Dangerous stuff.

Equally so for the corporate world.  Phantom risks are poorly made out inferences or assumptions, when misapplied, have teams chasing them for the life of the project.   This is commercially dangerous for 5 key reasons:

  1. It is a dangerous absorption  of executive time.
  2. It causes unnecessary management hysteria.
  3. Phantom risks fuel pet projects and hidden agendas.
  4. At best they increases drag on project, and
  5. At worst they dangerously misappropriates essential liquidity by artificially inflating the need for contingency.

More importantly, without an accurate, precise and robust quantitative methodology for identifying, defining and quantifying risk it is most likely that the corporate risk register will be full of phantom risks.

THE PURPOSE OF A RISK REGISTER

The purpose of a risk register is to define the amount of liquidity needed to cover unexpected project risk.  This means:

  1. Risk register risks must be below 50%.  If they are over 50% then they have a better than even chance of happening (i.e. they are expected) and therefore they should be managed in the baseline project cost model.
  2. Unexpected project risks – truly unexpected – should have liquidity assigned from outside the project budget.

The last point is a hugely contentious issue.  Logically, a project should not be saddled with the financial burden of improbable risks not of their making, i.e. if a project did not bake in its own risks by its own poor design and management then it should not have to pay for them when they occur.  The necessary contingency funds should come from Treasury.  This means that project teams are encouraged to sail as close to the wind as possible and are not penalised for doing so.

quopte

In most cases, however, savvy project teams will artificially inflate risks in order to create the greatest possible contingency.  These funds, held outside the project budget, then act as a black-budget slush fund for the project.  The nett result is a project which is more likely to hit its margin targets but an unhealthy corporate balance sheet.

WHEN IS A RISK NOT A RISK?

A risk is not a risk when it is an issue.  Much of the difficulty in generating real risks is that most risk register risks contain elements of risk.  They allude to risk and there is usually a gold nugget in there somewhere.  However, until there is a quantifiable financial impact they cannot be used to determine liquidity requirements and they should not be included on a risk register.  They may be pressing issues for the business but they are not risks. The difference is key:  Risks require liquidity.  Issues require analysis.

quopteMost risk registers contain risks which have no business relevance.  These things are, technically, risks but they are usually so remote or unprovable that they (i) are hard to argue with, and (ii) obfuscate the real risks often hidden within their confused semantics.  Most of these things are pressing business issues but issues require further analysis and planning.  They do not belong in a risk register.

HOW TO DEFINE A RISK

  1. Firstly, to be a risk a thing must satisfy the following criteria:
    1. it must be derived from a structural weakness, i.e. a design flaw in the program plan, the technical architecture, a contract clause, a cost model imperfection.
    2. there must be a threat/disposition.  For instance, a chair with the broken leg might highlight a structural weakness but it does not represent a real risk until someone becomes disposed  to sitting on it.
  2. Secondly, in order for risks to be commercially relevant they must satisfy the following criteria:
    1. they must be HOT:  They need to part of an emerging or ongoing adverse variance in the costs.
    2. they must be VALUABLE:  these variances must show high volatility in the cost model, i.e. if the risk is realised there will be worrying financial implications.
    3. they must be WEAK:  they need to be part of something (or dependent upon) that the business often gets wrong.  This is critical because adverse variances and financial volatility might merely represent the natural trajectory of a cost variance in a project.  There is often little cause for concern.  Unless, however, these variances are part of a statistical problem within the company’s projects.

If all the criteria above are satisfied and a relatively accurate number can be used to quantify the financial impact of the risk, then it is a real risk.  If it has high probability and was found during the estimating process then it probably needs to be managed as part of the Baseline and not the risk register.  If, however, it’s a low probability risk and not something the project team should be held responsible for then it likely belongs on a risk register (the funds for which should come from Treasury).

When done right this method usually reduces risks by 80%.  What is left are real risks which point to real liquidity requirements and the need for real action plans in order to minimise real legal exposure.  A risk register of such quality is useful and practical not only to Operations but also to Legal and Finance as well.  Most importantly, no one is chasing phantom risks.

Measuring Legal Exposure Reply

Mind the gapThe function of a contract is to cover legal exposure.  It does not, by and large, govern the relations between parties.  Those are already established by the community and contracts merely document well established facts.  The way the parties will behave will already be a an established reflection of their education, training and previous business experience.  It is naïve to think, for instance, that a contract will be used by engineers to help manage the construction of a building.  On the contrary, the contract will present a myriad of hurdles, obstacles, impasse and problems as the workers try to get on and do their job – build.  It is a truism to say then that almost all litigation is a function of poor contract management rather than poor contract design.  Indeed, I have never met a client who had either fully read OR fully understood the contracts they were in.

A contract, rather, seeks to cover the inevitable areas of risk when two parties necessarily compromise to enter into an agreement. as my father used to say, ‘there are two parties to a contract – the screwor and the screwee.  One party is always disadvantaged.  The lesser party needs to cover their legal exposure and the greater party needs to ensure that not so much risk flows down that the lesser party is overloaded with risk, making the contract unworkable. Picture1Legal exposure is derived from financial risk.  Contracts will generally cover most financial exposure.  However, in Westminster-based systems much of the law of contract is still based in Equity.  Usually, there is still some degree of exposure that remains.  A party can only be forced to  indemnify so much; can only warrant so much and not beyond the reality of the arrangement.legal exposure

Most contracts, however, do not measure the legal exposure a party faces.  Most contracts stick with the standard blanket coverage formula, i.e. zero exposure.  This approach is unhelpful and in many cases counter-productive, because namely:

  • Phantom Exposure.  contract negotiations become unnecessarily bogged down over non-existent risk.  Arguing for 100% coverage when the risk is well covered already is just chasing phantom risk.
  • Lazy.  Quite frankly, the body of knowledge which exists in each sector, the sophistication of clients and the modern quantitative tools which exist to make contracting easier give no excuse for legal laziness.

Measuring legal exposure is both qualitative and quantitative.  Firstly, deriving financial risk is a mathematical function.  Secondly, as exposure is derived from the limitations of contractual coverage then legal exposure is a function of qualitative assessments.

My own method uses a threefold approach, namely:

  1. sensitivity analysis to measure financial risk, and then
  2. three separate qualitative measurements to define whether an element is a legal risk, then
  3. a legal assessment to determine if the remaining elements are covered (i.e. measure the exposure) and to what degree.

All of this is done as a collaborative process around a single bubble chart (shown below).  As is shown in the chart,

  • the bubble size (Z ‘axis’) relates directly to the mathematical analysis of financial sensitivity.
  • the X-axis is a qualitative scoring designed to assess the relative complexity of each item of volatility.
  • the Y-Axis is another qualitative scoring to determine just how close the item is to the project team, i.e. can they actually do something about it?  The less a team can influence a risk the more such risk needs to be pushed upwards so that the corporate functions of a business (Legal, Finance) can act upon it with centralised authority,
  • the colouring, lastly, deals with the notion of immediacy, i.e. prioritisation.

In this way, if a risk is both very complex and not able to be influenced by the project team (i.e. cannot be mitigated) then it, most likely, needs to be dealt with by the Legal function as there will be no way to otherwise influence it when the risk is realised.

Risk-Based Bubble Chart to engender cross-functional collaboration

Once legal risk is conceptually isolated in the upper-right quadrant of the bubble chart then lawyers may make a qualitative determination as to the amount of legal exposure.  For instance, a builder may warrant the quality of workmanship on a specific structure and cover it with insurance.  Legal may determine that there is virtually no statistical evidence that such risk is likely to be realised.  Therefore, the existing premiums easily cover the risk highlighted in the chart.

Alternately, the chart may have defined financial risk beyond, say, the indemnities provided by a firm’s subcontractors.  In such a case insurance or contractual renegotiation may be necessary.  It is important to know that in such circumstances it is precisely targeted cross-functional management energy that is being expended to determine, define and collaboratively deal with specific  financial risks.  Indeed, there is little more any business could hope for.

Hidden Costs in ICT Outsourcing Contracts Reply

hidden-costs

Why are IT outsourcing contracts almost always delivered over-budget and over-schedule?  Why do IT outsourcing contracts almost always fail to achieve their planned value? How come IT contracts seem to be afflicted with this curse more than any other area?

Quote

The common answer is that (i) the requirements change,  and (ii) that handovers from the pre-contractual phase to in-service management are always done poorly.  These are both true although hardly explain the complexity of the situation.  If requirements change were an issue then freezing requirements would solve it – it doesn’t.  The complexity of large ICT projects is derived directly from the fact that not all the requirements are even knowable from the outset.  This high level of unknown-unknowns, coupled with the inherent interdependence of business and system requirements, means that requirements creep is not only likely but inevitable.  Secondly, (ii) handover issues should be able to be solved by unpicking the architecture and going back to the issue points.  This too is never so simple.  My own research has shown that the problem is not in the handover but that the subtleties and complexities of the project architecture is not usually pulled through into the management and delivery structures.  Simply put, it is one thing to design an elegant IT architecture.  It is another thing entirely to design it to be managed well over a number of years.  Such management requires a range of new elements and concepts that never exist in architectural design.

The primary factor contributing to excessive cost (including from schedule overrun) is poor financial modelling.  Simply put, the hidden costs were never uncovered in the first place.  Most cost models are developed by finance teams and uncover the hard costs of the project.  There are, overall however, a total of 3 cost areas which must be addressed in order to determine the true cost of it outsourcing. 

True Cost of IT

1.  Hard costs.  This is the easy stuff to count; the tangibles.  These are the standard costs, the costs of licensing, hardware, software etc.  It is not just the obvious but also includes change management (communications and training).  The Purchasor of the services should be very careful to build the most comprehensive cost model based on a detailed breakdown of the project structure, ensuring that all the relevant teams input costing details as appropriate.

2.  Soft Costs.  The construction industry, for instance, has been building things for over 10,000 years.  With this level of maturity one would imagine that soft costs would be well understood.  They are not.  With project costs in an extremely mature sector often spiralling out of proportion it is easy to see that this might also afflict the technology sector which is wildly different almost from year to year. 

Soft costs deal with the stuff that is difficult to cost; the intangibles:  The cost of information as well as process and transaction costs.  These costs are largely determined by the ratio of revenue (or budget in terms of government departments) against the Sales, General & Administration costs, i.e. the value of the use of information towards the business.  Note that this information is not already counted in the cost-of-goods-sold for specific transactions.

Soft costs go to the very heart of how a business/government department manages its information.  Are processes performed by workers on high pay-bands?  Are workflows long and convoluted?  The answers to these questions have an exponential effect on the cost of doing business in an information-centric organisation.  Indeed, even though the cost of computing hardware is decreasing, the real cost of information work – labour – is increasing.  This is not just a function of indexed costs but also the advent of increasing accreditation and institutionalisation in the knowledge worker community.  Firstly, there is greater tertiary education for knowledge work which has hitherto been unaccounted for or part of an external function.  The rise of the Business Analyst, the Enterprise Architect (and a plethora of other “architects”) all serve to drive delivery costs much higher.  Not only are the costs of this labour increasing but the labour is now institutionalised, i.e. its place and value is not questioned – despite the data showing there seems to be limited economic value added through these services (i.e. no great improvement in industry delivery costs).

3.  Project Costs.  Projects are never delivered according to plan.  Requirements are interpreted differently, the cohesion of the stakeholder team can adversely impact the management of the project, even the sheer size and complexity of the project can baffle and bewilder the most competent of teams.  Supply chain visibility, complicated security implementations and difficult management structures all add to project friction and management drag.  There are many more factors which may have an adverse or favourable effect on the cost of performing projects. 

IT Transition Cost Graph

In the Defence community, Ph.D student Ricardo Valerdi created a cost model – COSYSMO – which isolated 14 separate factors peculiar to systems engineering projects  and gave these factors cost coefficients in a cost model.  Ultimately, each factor may be scored and the scoring then determines the effort multiplier, usually a number between approximately 0.6 and 1.8.  Naturally, when all factors are taken into account the overall effect on the contract price is significant. 

More importantly, for IT implementations, the “project” is not short.  IT outsourcing projects are generally split into 2 phases:  Transition and Transformation.  Transition involves what outsourcers call “shift-and-lift” or the removal of the data centres from the customer site and rear-basing or disposal of the hardware which allows the company to realise significant cost savings on office space. 

During the second phase – Transformation – the business seeks to realise the financial benefits of outsourcing.  Here, a myriad of small projects are set about in order to change the way a business operates and thereby realise the cost benefits of computer-based work, i.e. faster processes from a reduced headcount and better processes which are performed by workers on a lower pay-band. 

IT outsourcing  is not just about the boxes and wires.  It involves all the systems, hard and soft, the people, processes and data which enable the business to derive value from its information.  Just finding all of these moving parts is a difficult task let alone throwing the whole bag of machinery over the fence to an outsourcing provider.   To continue the metaphor, if the linkages between the Purchasor and the Vendor are not maintained then the business will not work.  More importantly, certain elements will need to be rebuilt on the Purchasor’s side of this metaphorical fence, thus only serving to increase costs overall.  The financial modelling which takes into account all of these people, processes and systems must, therefore, be exceptional if an outsourcing deal is to survive.

Enterprise Architecture: Is there any such thing? 3

I should preface this post by saying that I am a huge fan of enterprise architecture and have been for some time.  However, I posit that there is simply no evidence that enterprise architecture actually exists or will ever exist.

If EA were working or was economically viable we could have expected a decline in the global outsourcing market as businesses sought to integrate and consolidate applications along an enterprise metamodel.  However, this work predicates a level of control and ownership which is not consistent with applications/business process outsourcing.

Global Outsourcing Market

Definitions of EA aside, it seems clear to me that the economic benefits of EA simply cannot compete with the economic benefits of outsourcing.  In order to turn the tide, my personal opinion is that EAs need to be able to architect from the financial instead of the minutiae of the technical.  Stop trying to solve technical problems and start trying to solve business problems.  More importanlty – in line with the ‘E’ in enterprise – be able to cut through the petty bureaucracies and fiefdoms of middle management and begin to define business problems by calibrating financial statements with technical information.  In other words, how can technical architects analyse adverse financial variances on the monthly balance sheet and turn them into changes in the technical development or delivery?  What is the technical implication of a month-on-month 17.5% adverse variance on Indirect Labour?  Until these figures become the mainstay of an Enterprise Architect’s work then EA will never be able to compete with the simple value proposition of outsourcing, i.e. “it’s not working! give it to an expert.”

More importantly, in virtually all businesses (i.e. non-tech businesses) the company is defined by accountants and sales people.  Operations comes in close second and IT is so far at the back of the corporate parade that it can’t even hear the marching band play.  In order for Enterprise Architecture to morph into something useful – and something closer to what I imagine Zachmann imagined – it will need to deal with enterprise engineering.  This is the difference between systems engineering and Engineering Systems, i.e. the engineering of information between the various systems/functions in the business.  What is the atomic meaning of a cost variance in IT terms? 

Until EA/EE can truly grasp the complexities of the enterprise it will only ever be IT window-dressing.  In the meantime, I hope I’m wrong.

Qld Govt On Track to lose Billions Through Poor Outsourcing Reply

In a recent article in online technology ezine Delimiter – “Qld Health Preps Huge IT Outsourcing Deals” – Renai LeMay points out that the Qld government will need to spend an unadjusted $7.4 billion over the next 5 years in order to replace and upgrade 90% of its outdated ICT portfolio.

The question is whether it has learnt from the Qld Health outsourcing debacle with IBM and will it move forward with its best foot?  It is unlikely, given that HSIA seems thrust into the contracting process too early with too little.  With the pace seemed to be set by the Costello audit, the HSIA is now engaging in early vendor ‘discussions’ (IBM notably excluded) without even a detailed set of business requirements, system parameters and financial boundaries.

In letting vendors shape the early development of these outsourcing contracts the government is on track to lose billions.  This will happen for 3 primary reasons:

  1. Service Management will be overlooked – The failure of virtually all contracts is not in the structure but the management.  Although most experienced litigators have gasped at contracts (usually government) which seemed to have been designed to fail (largely due to something bordering on corruption or undue influence), most are not so designed.  Outsourcing contracts, more than any other, require detailed attention to the management of the service.  Ultimately, the difficulty lies in the paradigm shift from network support to service management.  In other words, the personnel in charge of servicing are now in charge of service management.  In most cases, these jobs are made redundant as the vendor takes them over (unlike TUPE laws in the UK).  Consequently, the knowledge is lost.  Purchasors can protect themselves against service decline by making the vendor buy key personnel.  Better yet, Purchasors should transition these key roles from performing the work to managing the service/contract.
  2. Deals will be too long – Vendors will push longer outsourcing contract lifecycles.  Although, prima facie, there is  nothing long with a long contract it is imperative that such contracts are designed to be managed, i.e. the focus is on the delivery and management Schedules and not the boilerplate of the Operational clauses.
  3. Tech bundles will lack modularity – Qld government loves to re-organise.  After each government their is always a paradigm shift in the Machinery of Government (MOG).  Departments shift and with them so do budgets and internal processes.  These are generally managed within departmental parameters with necessary roles and functions often going unfunded and unfilled for entire cycles of  government.  To reinforce Renai LeMay’s point, it goes without saying, therefore, that the government needs to develop a modular, multi-bundle architecture wherein departments can buy and sell service credits between themselves without limiting the overall strategic cost savings.

In summ, there are numerous ways in which Qld government can guard against the inevitability of cost overruns and poor, overly simplistic outsourcing contracts.  On the other hand, the vendor which offers these first will have a significant advantage.  in many cases, the difficulty will be in convincing QGCPO that novel and innovative contracting vehicles are there for the benefit of the Purchasor and not just vendor voodoo. 

CIOs warned against long outsourcing contracts Reply

In a recent article in online magazine IT News, government CIOs are actively warned against signing long term service deals.  Mike Lafford, from Gartner, advises government CIOs against long term contracts. 

Please, please, please, don’t sign ten year deals.
– Mike Lafford, Gartner

Logic favours a longer contract in order to squeeze more value for money from a vendor by allowing them greater economies of scale (i.e. more guaranteed revenue = more borrowing power = bigger, better service infrastructure).   However, Mr Lafford notes that the contracting process is so long and tedious that vendors artificially force up their margins to cover the enormous costs of business development and tendering.  Government departments, therefore in particular, do not see cost benefits.

Current outsourcing contracts show a level of sharp practice and degree of innovation usually reserved for used car sales

Lafford, however, does concede that there are 3 artificial factors which increase both the risk and costs for vendors, namely:

  1. Transition Costs are High – Departments  are told they place an unusually high management burden on vendors by ‘creeping’ into contracts.  Long evaluation periods and bespoke management structures all serve to drive up vendor costs.  Purchasors should align their management structures with the, relatively, inflexible service delivery of the vendors.  In addition they can give the vendor a 3-6 month Service Credit holiday  with a Buy-Back/Call Option at the en.  In this situation all current infrastructure remains in place and the Buy-Back option (purchase for the base cost of transition) is contingent on a stipulated average service performance level well below market benchmarks.
  2. Vendor Risk in Technology/Business Change – Primary risk is derived from reduced volume/numbers, e.g. in desktop support.  There are 2 possible ways to deal with this:  (i)  sign a deal involving multiple departments.  Hedge overflow costs buy buying and selling capacity amongst departments/teams.  Secondly, (ii) pay for the minimum not the maximum and then buy overflow capacity.  Departments and teams are always looking at headcount reduction so don’t buy at your maximum capacity but do expect/ensure good discounts (on an increasing scale) for more capacity.
  3. Inflexibility in Contracts – The current thesis is that long contracts are inflexible contracts.  This is nonsense, although technology contracts can be far more complex than PPP contracts, for instance, for the reasons stated above, i.e. lack of clarity in the future requirements.   The focus of most contracts is on the ‘operational clauses’, i.e. boilerplate governing standard business relationships.  Failure of outsourcing contracts, however, is almost always with the failure of contract management (by which we usually mean “service management”).  In order to develop a contract which changes over time, the focus of the contract must be in the Service Management Schedules. 

In summ, governments and businesses alike have to realise that someone pays for risk.  If they place risk with the vendor then the business/department ultimately buys it back.  To that end, I would usually recommend a 5+5 contract.  The trick, however, is not with the development of the KPIs but rather with the management of the service.  To that end, Purchasors should not underestimate the detail they need to go in to when developing their service management structure.