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.

Protecting Information: a cascading approach to information security Reply

There is no easy way to protect corporate information.  Protecting government information is easy because they have their own networks.  Life in commercial society is somewhat more different but if businesses follow these 6 steps they will be better off:

  1. DEFINE. Don’t protect everything.  It costs too much and it’s a waste of time.  Define what is intellectual property (patents, trademarks etc).  This is the stuff that (a) is legally protectable, and (b) it is what the market will pay for (i.e. it isn’t an intangible asset – it has dollar value).  Intangible assets which are collectively seen as valuable are classed as intellectual capital.  Everything else is either supporting information or junk.  
  2. DETERMINE.  Determine what goes where as part of your internal processes and workflows.  Remember, it gets used if it’s part of the workflow.  Proper IP should reside on closed systems with certain roles acting as guardians, e.g. in-house counsel, financial comptroller etc).  Intellectual capital, things such as frameworks, processes, analytical methods should sit on systems with role based access privileges  so that repeated access (e.g. for screenshots) is noted. Printing and downloading should be limited and part of a defined process.  Thin client technology helps but the most important means of guarding this stuff is to make it compartmentalised (i.e. various levels of decomposition etc) so that it’s hard to gather it all together it once yet easy enough to use as a reference tool for team use.
  3. DEVELOP.  Keep developing your intellectual capital.  It’s less worthwhile stealing information which is outdated.  Moreover, make sure that development is cross-functional and multi-disciplinary.  This is akin to holding the encryption key to your intellectual capital.  If only a few central people know how the framework all works together then even if it is taken by former employees they will, at least, be unable to build on it.
  4. IDENTIFY.  Identify the people who are going to access this sort of information.  Now build these roles and enforce them with internal business processes and physical security measures to make this work.
  5. INSPECT.  Tag your information and gain access to employee hard drives.  There is no way around it.  Be subtle about how you approach knowledge workers and develop socially enforceable norms around the use of corporate proprietary information.
  6. INVEST.  For intellectual capital works invest in a great means of display.  If you’re afraid of other firms ripping of your frameworks or processes then get a graphic artist to create excellent visual representations.  Then you can protect that image through contracts with employees and clients.  Any use outside of your parameters can be met with a solicitor’s letter.

Most importantly, invest in your people and invest in the development of new knowledge.  If they want to take it, they will but nothing secures information like happy employees and few will want to steal outdated information which they can’t build on.

Business Architecture: just coding bad culture? Reply

Business architecture  seems to move from the pointless to the absurd.  Why do organisations spend so much time and money on documenting business processes and requirements only to see nearly all IT system deployments run over time and cost?

Can It Ever Be Useful?

Technically, by modelling business processes the business analyst (BA) should be able to derive the functional requirements of a system  – largely by analysing “events”.  Here’s how it should happen:

  1. The BA derives the Business Process Use Cases from the analysis of  process documents.
  2. The BA then works with the business to devise ‘realisations’ of these use cases.
  3. The realisations are then analysed for System Use Cases.
  4. The system analyst (SA) then works with the tech teams to design system realisations which instantiate the system use cases.
  5. Then the programmers work to code all this so that the new system does exactly what the users wanted, i.e. business functionality.

So Why Does It Never Work?

The litany of well documented IT project failures highlight the fact that this process usually does not work.  Although the process is clearly broken it is not fundamentally flawed.  Firstly, requirements structures are over-simplified and their levels of abstraction are confused.  This means that the link between most business modelling and business use case development is intuitive and a leap of faith.

The process of requirements development is well documented in the Rational Unified Process (RUP) and well supported by sysML, UML and Business Motivation Modelling (BMM).  It is usually through a lack of BMM, however, that the process falls down.  Not only does the process not work it also serves to hard-wire bad culture into the business.  By designing software from poor requirements the business not only increases the cost of future change (approximately equal to x100) but it also ends up coding bad culture – the very culture/processes they wanted to steer away from by designing new software.

Picture1

So What Is The Value Of BPM?

Apart from the sheer cost saving ability of a sleek requirements process, Business Process Modelling has great value in automating processes.   BPMN models can be exported to BPEL and executed as computer processes.   This gives huge flexibility in orchestrating complex process and workflows between machines. 

Designing Directly from the Value Chain

The real power of good business modelling is when it gets ahead of the design curve and starts developing business architecture directly from the Value Chain.  By analysing the hot-spots in the finances and then determining whether they are valuable-spots within the Value Chain, business architects can begin to develop or rationalise designs before they become pet projects.  This is not done already, largely, because accounting standards mean that (a) costs are not coded according to a business’ Value Chain, and (b) virtually no business has a well documented Value Chain to start with.  However, it is a valuable exercise to understand the correlations and dependencies between what a business spends money on and how it earns revenue.  Who better to do this than the business analyst/architect?

Competitive Advantage in IT 1

Although a recent article in SearchCIO alludes to competitive advantage by IT departments, arguments like this can take the CIO down a dangerous road.  The holy grail of many CIOs is to run a department which is both profitable and also increases business capability.  Mostly, however, IT departments are costly and the subject of constant complaint.

Can IT ever be a profit centre?

Economists have long argued that businesses should strip away overhead (i.e. not included in the cost of goods sold but pure overhead) cost chargebacks from business verticals and their processes in order to gain a clearer view of what is profitable and what is not.  If they don’t then smaller, profitable processes are often in danger of being swamped with overhead.  In this way, many businesses often outsource or cut the wrong activities.

It is notoriously difficult to cost IT chargebacks so that market verticals are charged just the right overhead.  Should businesses charge their verticals for email?  They often do but isn’t this just a cost of business that the centre should absorb?  Isn’t the burden of communication and reporting largely placed onto verticals anyway?  So if they could run their business units in a more entrepreneurial way wouldn’t the cost of IT be significantly reduced? 

What if we extend that argument and let IT be a profit centre?  Why don’t we let business units find cheaper ways of doing business and compete with the IT department?  Security/integration/management time arguments aside – it is likely that if IT departments were able to charge for the thing they were really good at, this would be a source of competitive advantage within the business.

So, there is a good reason why IT departments aren’t profit centres but, of course, this doesn’t solve the problem of the high cost of IT inside business.

The Perfect Storm for Cloud Computing? T Reply

The Perfect Storm for Cloud Computing?

There is no doubt that cloud computing is the technical elixir of our time. Unlike standard corporate virtualisation/thin client operating models the current technology provides 3 things in unison:
1. Huge processing capacity allows powerful software to run complex computations on very small devices.
2. Commoditisation means that there is a huge range of cloud-based software out there.
3. Commoditisation plus the simplicity of developer platforms has meant huge downward cost pressures.

Is this the perfect storm?

No.

In order to create the perfect storm 1 additional factor would need to be present; Personal Virtualisation.

In order to create a competitive advantage through differentiation (particularly for professional service firms and other knowledge workers) the cloud computing offerings needs to provide for personalised virtualisation of applications or whole systems.

Although this is possible now it is not commoditised to the extent that it allows standard lay people the opportunity to take advantage of it. When this happens and knowledge workers can access highly specialised/customised niche apps through web browsers, then we can say that ‘cloud’ has come of age. http://ow.ly/jjc2F

Gartner Executive Program Survey of More Than 2,000 CIOs Shows Digital Technologies Are Top Priorities in 2013 Reply

“The survey showed that CIO IT budgets have been flat to negative ever since the dot-com bust of 2002. For 2013, CIO IT budgets are projected to be slightly down, with a weighted global average decline of 0.5%.”

Gartner Executive Program Survey of More Than 2,000 CIOs Shows Digital Technologies Are Top Priorities in 2013.

The survey clearly shows that projections of huge IT spend increases are fanciful.  CIOs are not only being asked to do more with less but are also being asked to help innovate and expand with less.  New investments will need to show a clear ROIC if they are to be approved. 

Ideas for innovative technological support to the business will not be the problem.  CIOs will need create new ways of measuring the value they deliver to the business.  In developing business cases for MIS they will need to move away from NPV analysis and start to measure the net increases in managerial decision making and knowledge capital.  It is only then that IT departments can start to pull through emerging technology quickly to create corporate value faster.

EA as Strategic Planning: I’m Still Not Convinced Reply

Business and TechnologyA recent blog entitled: “EA is Strategic Planning” highlights a sentiment by many enterprise architects (a widely abused moniker) that what they are doing is new, ingenious and necessary.  I’m still not convinced.  Whilst one cannot decry the skills, expertise, knowledge and ability of many enterprise architects I am yet to see a cogent argument that what they do is either cost effective or necessary.

Heresy?  Hardly.

The enterprise has done remarkably well since the Dutch East India Company was granted its royal license in 1600.  The rise of the  enterprise has not abated and diversified companies such as Du Pont and ITT have shown that complexity and size are no obstacle to good, valuable shareholder growth. 

IS EA JUST GOOD IT?

I am in two minds:  (i) EA has certainly helped the IT community with complexity by bringing a portfolio view ICT programs, but(ii) EA has added no significant value to a listed company (beyond just good sense, well delivered IT programs) or reduced its risk to such an extent that would warrant dedicated EA. 

EA has likely been the product of a traditional lack of the requisite skills to translate the social value of collaborative software into corporate monetary value.  It is worth noting that embedded systems (such as robotics) and operational systems (systems that a given corporation simply cannot perform its operations without) are not included in this assessment as their value to the business can be calculated in a simple NPV assessment of projects, i.e. the system will directly result in higher discounted cash flows.  That this should be the job of a programmer is nonsense.  That large commercial enterprises are only beginning to adopt social media systems (which people have been using for years) highlights the general inability of enterprises to grasp the financial value of subtle and complex ICT.

SO WHAT DOES EA OFFER?

Enterprise architecture is not strategic planning.  As much as I like David Robertson’s book “Enterprise Architecture as Strategy”, it is farcical to suggest that the structure of an organisation should either come first or drive (other than the broad parameters)  the functional design of the business model.  If EA is to deliver value to the organisation then it must reach beyond large, complex IT.  To add real value it must be the the function which is capable of reaching across the business siloes to solve the problems which the corporation does not even yet know it has.

ENTERPRISE ARCHITECTURE AS A SEPARATE DISCIPLINE

Enterprise architecture must grow out of its humble ICT beginnings if it is to have the boardroom caché and intellectual gravitas necessary to drive strategy.  EA must develop beyond it systems engineering fundamentals and extend its validity into the statistical relationships between technology structures, information performance and shareholder return.  Only in this way will EA be able to communicate the financial return which subtle and complex MIS systems can add to a company.  Whatever enterprise architects believe they can do they will not get the opportunity to display their value, beyond simple tenders, unless they can convince the finance function.

2013: Not The Year Of The CIO – Yet Reply

It is highly unlikely that this will be the year of the CIO.  Tom Curran is entirely correct that CIOs need to get closer to business units to prove their value.  After years of uncontrolled IT budgets and then recent vicious cost reduction programs CIOs need to prove that they are more than email, storage and security.  CIOs need to be proactive in supporting the cost of businesses and that means developing capability.

Firstly, there are 3 types of business tech: (i) embedded systems such as robotics, (ii) operational systems such as customer ordering systems, and (iii) management information systems  such as email, ERPs, ERMs, collaboration tools etc.  The first two are largely accounted for in the cost-of-goods-sold but the latter is usually accounted for as overhead in SG&A.  Although their worth is unquestionable (could a large company really do without email these days?), it is these MIS systems which are notoriously hard to prove the value of.

There is still little evidence that MIS directly increase profitability.  Corporate IT spending largely increases in accordance with SG&A costs which tells us 2 things: (a) that as companies grow and increase their revenue they increase their management commensurately, and (b) IT is bought to connect this management.  There is not some inflection point where systems are bought, magic happens and companies become organised.  Organisation is the job of the business but enabling that by bringing distributed human communities together through electronic communications is the primary purpose of MIS.

Picture1

In order to become the critical enabler that it has always wanted to be IT needs to focus on capability and not just costs.  Although Tom suggests that this will be achieved through in-house architects I would suggest that in-house capability is too hard and costly to maintain at the requisite level to actually analyse and build business capability.  The only function that should be retained and honed, in-house, is information mangement.  Businesses need to be absolutely certain about exactly what information (at an atomic level) actually makes them money  – and how.  Outsiders without the context, peripheral information, subtext and political insight cannot adequately contribute to this role.  Only once the business understands its financial the anatomy of its fianancial dependencies can it adequately source architectural support in order to build business capability.  The business which misses the point and only develops architecture is just gilding the lily and will just be rewarded with a higher overhead burden which they need to chargeback to disgruntled internal customers.

Is this achievable in 2013?  The likelihood of this belies my underlying assumption that CIOs do not belong in the C-Suite.  As critical as technology and information is to business it is only a critical enabler and not a separate function in itself.  Due to the radically different skills which the technical community possess I do not believe that they will ever be able to set the agenda in non-digital industries.  Putting CIOs in the C-Suite merely overemphasises the importance of technology as an end and not merely the means.  It is here I think that standard operations should stop abdicating its responsibility and start setting the technical agenda and this will certainly not happen in 2013.