The Value of Information Reply


Information is expensive, of that there is no doubt.  The cost of information technology as a percentage of revenue remains high despite falling capital costs and the cost to maintain specialised management skills to sort and interpret the incredible volume of information.  The question is whether information is actually financially valuable.  Companies spend a large amount on managing information but what return do they see?  What is the value-added figure for information?

Information Value-Added = (Total Revenues + Intellectual Property + Intellectual Capital) – (operations value-added – capital value-added – all purchases of materials, energy and services).

This is to say that once all labour, expenses and capital (that is not part of an information system) is accounted for, the cost is subtracted from the total of gross revenues (plus IP).  In other words, it is the part of the profit which is not directly accounted for by operations or increased capital value.  It is profit which is attained purely through better managerial decision making.  This might be achieving better terms and conditions in the supply of a product or it might be in the reduction of insurance costs on a given contract.


Note that I include the term ‘intellectual capital’.  I define intellectual capital as an information asset which, if valued, would increase the value of the firm.  This is not to say that the information asset itself has value (such as patents and trademarks which may be bought and sold and therefore are IP) but rather information such as mailing lists, customer preferences, methodologies, databases etc.  These are generally valued in a business as goodwill but ideally should be valued separately.


Information value as an index can be calculated through the ratio of Information value-added divided by information costs (see previous blog). So, in any given business unit the value of its information is the additional money earned from management’s better decision making.  If this results in better operations then this is ‘operations value-added’ and should not be included.  However, increased revenue not directly attributable to operations should be included as ‘information value-added’.


The standard answer is no.  In most companies and business units gross revenues (plus IP/IC) may increase but unless unit labour costs and technology costs are kept in check then the overall productivity of information is limited.  In many managerial accounting case studies the value of information is counted as being gross revenue less the cost of IT (where the analysis takes place in a non-operational function such as purchasing).   However, with reductions in IT capital costs over the years one would assume that the ROIC from IT is great.  By adding associated increased labour costs, however, the story is different.  Year on year declines are evident.  The story is clear – information is no longer adding much value in business.


In order to achieve greater value from corporate information a business must do 2 things:

Firstly, reduce per unit managerial labour costs.  Instead of merely reducing head count the per unit cost of management should be reduced.  In this way the company is working cheaper not harder.  Overall headcount should be the focus of operational process performance enhancements and not structural adjustments.

Secondly, increase profitability from managerial, non-operational decision making (because operational decisions are subject to their own dynamics).  With a renewed focus on (non-operational) decisions which increase profit or reduce costs businesses will find that their ratio of earnings:information cost indices increase favourably.


In order to achieve a greater return on invested capital companies seek to ‘sweat the assets’.  However, labour costs associated with processing and managing information will always rise faster than capital expenditure for IT (as well as associated operational expenditure for service costs of cloud computing).  Sweating IT assets is of limited value since they depreciate so quickly that they have no value virtually as soon as they are purchased.  In fact, increasing the value of information will largely come from increased revenue from higher management performance not from lower IT costs.  So, in order to achieve a greater return on information companies should seek to ‘sweat the management’.

The Architectural Enterprise: developing an EA program in an organisation Reply


Enterprise architecture is what happens not what an organisation does.  The teams, roles, structures and functions already exist within most organisations. The benefits of an enterprise architecture are best driven from a central, cross-functional governing body which has the power to (a) analyse the business and (b) drive alignment of the technical architecture.

EA is not a separate team or function.  EA is best achieved from a high-level by linking the functions of teams and business units. Most businesses already have enough EA structures already  in place.  The usual failing is focus not facilities.

Using an active governance, risk & compliance framework enterprises can ensure alignment of business capability and technical architecture.  To achieve this businesses should focus on the following 3 steps:

  1.   Focus on Business Capability not technical architecture.
  •   Use financial modelling.
  •   Use Value Chain modelling for alignment.
  •   Use parametric modelling to ensure that capability does not decrease with costs.
  1.   Become a source of value for the business.  Offer capability development into the Strategic Business Units.
  •   It is the only way to get full visibility of their cost structures.
  •   Build better stakeholder buy-in for complex projects.
  1.   Enterprise Architecture best sits within the GRC function.  An Architectural Council (Tier 2 executives) which helps provide the focus for architectural development.
  •   Reinvigorate the Business Lifecycle Governance Process with dynamic assurance measures.
  •   Remove much of the onerous, burdensome program review and develop a more analytical assurance based model.

The Construction of Contracts: Problems with Plain English for the Interpretation of Legalese 1

Lawyers have long been derided for their use of verbose and complex language.  Businesses often criticise legal teams for turning simple commercial agreements into indecipherable esoteric jargon.

The state of legal drafting is likely to be responsible for a large portion of the commercial litigation occurring these days.


When I was at law school someone asked why judgements were written in such complicated language.  The lecturer gave the rather unsatisfactory answer of “well, they just are, so I suggested you get used to writing like that as well.”  So begins the institutionalisation of the legal mind.  Whilst lawyers argue that complex topics beget complex documents it need not always be the case.  It is simply not sufficient to argue that circumlocutory language is essential to navigate the labyrinthine technicalities of the law.


The problems is not the generation of meaning it is surviving interpretation.  For instance, it is one thing to explain a business model so that your nine year old daughter understands it.  It is another thing entirely for the same language to stand up to intense scrutiny from another party who stands to lose money on that interpretation.

The phrase lawyers use is “covering the field”.  Lawyers reduce the penetration of an attack by reducing all the avenues of construction so that there is only one possible interpretation.  What is left is usually a wordy cocktail which is so complex that it defies the very interpretation intended.


The problem with plain English is that it dumbs-down complex concepts.  Jargon, on the other hand, usually arises in two situations:  (a) where the author seeks to look cleverer than they really are, and (b) where the author is trying to convey complex concepts precisely to an audience of the same background understanding.

The fact is that English is an imprecise language.  It is no wonder that French is the international language of diplomacy.  For instance, in English we have no gender for our nouns.  There is no way of telling which preceding noun the ‘he’ or ‘she’ of a sentence relates to.


Understanding, therefore, is created through a common conceptualisation not the design of the language.  Two builders, for example, will understand an agreement to build a house based on the architectural schematics.  Two bankers will, likewise, understand the securitisation of debt and sale as a derivative.  Both of these contracts will be entirely opaque to most of us and certainly to the nine year old daughter.

The trick, therefore, is in the creation of a common conceptualisation, one that is understandable and interpretable to the rest of us.  “The rest of us” should include the judge and expert witnesses should the matter ever be disputed.


English, therefore, is not the problem.  Architecture is the problem.  Agreements fail through the inability to create a common operating model.  Much can be brought over from the building and construction industry wherein the architecture, engineering and schedule form key artefacts of the business agreement and reduce ambiguity and uncertainty.  Likewise, where parties create an easily interpretable model (physical or conceptual) then the likelihood of  ambiguity, misinterpretation or, perish the thought, obligation avoidance, is greatly reduced.  Defence departments are moving this way through the use of Defence Architecture Frameworks (such as MoDAF, DoDAF and NAF) although none are optimised for the use in legal documents just yet. However, it will be a long time and only with huge a huge push from the business community that the state of legal drafting will change for the better.

Commercial Assurance Reply


Assurance is the function of checking.  Commercial assurance is the function of making sure that that value is not only retained but maximised as projects move through the various corporate silos of the business lifecycle.

In the perfect company as a deal or project moves from business development to financial analysis to Design and then through to Projects & Programs and on to Operations & Management the numbers and analysis flow seamlessly through each function.  Each department is able to take the preceding analysis and add value creating a streamlined contracting and management process that maximises profit and minimises risk.

The reality is a lot clunkier.  Internal entropy and friction are enormous.  Departments fail to understand each other, analysis is duplicated, documents are endlessly re-created and  spreadsheets re-formatted. In many cases it is a wonder anything gets done at all and mostly deals get done despite the business.

Most companies have a raft of commercial assurance and contract management procedures but they seldom join up in a coherent and comprehensive governance framework. Divisions and departments expend vast amounts of additional effort trying to understand each other and make sense of documents and numbers.  As this functional entropy increases so too does risk as cost centres and teams attempt to pass risk off to the next business unit.  Costs increase as do delays as risk becomes baked-in to the project.

Getting to the bottom of such a mess requires sophisticated tools, deep cross-functional knowledge, comprehensive cross-sector experience and a consolidated framework of understanding which increases process convergence from all parts of the business.

Commercial Assurance is the nexus of good commercial management, good project management, good legal advice and good architecture.  It has the following key benefits:

  •   Increase Business Process Efficiency and Value.
  •   Increase Confidence in Governance.
  •   Reduce Risk.
  •   Increase Profit.

A good assurance function will achieve these results by maximising process convergence and then optimising process performance.

A Framework for Contract Design Reply


Legally binding contracts can be designed with greater speed and precision using an architectural framework.

I have long been impressed by the way software design methodologies can cope with the translation of rich requirements sets and turn them, quickly, into an app.  A lawyer, on the other hand takes a rich set of client requirements and tries to turn them, quickly, into a contract.  The difference is?  Very little, really.

Architectural Contract Design

Modifying the Krutchen framework for use in the design of contracts


Process aside, the software developer has to implement an app within a complex governing framework of coding semantics and rules.  The lawyer has to draft a legally binding agreement within a governing framework of laws, semantic guidelines and regulations.  The key difference is that the software developer has to develop something that is useful, meaningful and practical to the user whereas the lawyer’s client won’t usually be able to understand what they’ve got and generally takes it on trust.

With this in mind I’ve adapted Phillipe Krutchen’s 4+1 design framework to contract drafting.  I’ve always liked 4+1 as a framework for design as it forces the architect to separate the logical from the physical.  It’s not too heavy and it’s not too light.  This is invaluable as a lawyer because it forces me to create a logical implementation of the client’s goals (the preferred operating model) and then implement that in physical terms (the contract clauses).  It forces me to concentrate on what is important to the client – the business objects (products, services and IP capital) – and not on the law.  It makes me get the point – and get to  the point fast and effectively.


The collaboration (the subject of the contract) is a business thing but the contract is a legal thing.  Or is it?  The contract should be a business thing.  A contract is the instantiation of the client’s preferred operating model. It should not be a legal creation although it is legal documentation.  It represents how the client wants to do business with the other party and what is important to them.  It is the agreement over how 2 parties wish to be bound as they collaborate over a thing.   As a commercial consultant I have worked in companies on contractual disputes where neither party had read the contract, nor were they using it to solve the dispute.  This was multi-million GBP stuff and nobody cared about the contract.  Contracts should be about the business, they should be about how we manage things and people and they should be dynamic and usable (more on that another time).


The design framework above closely resembles Krutchen’s framework but with 2 key differences.  Firstly, the physical implementation is not a technical architecture but the contract clauses themselves.  Secondly, I needed to take account of time so I added a Change View.


The fundamental aspect of a complex evolving system is how it changes over time.  When constructing a building the architect’s plans will change subtly as the engineers work around issues, materials are too expensive and delays are managed.  The contract may be varied formally, informally or not at all.  In all complex contracts the stakeholder landscape morphs over time.  The contract must take time into account and few, if any, contracts ‘do’ time well.

In order to do time well we need to understand how the business objects in our contract change over time.  By this I mean the physical and conceptual fruits of one’s labour.  This could be a car or a computer program.  If you need to redesign a car over time to keep it competitive then these changes need to be taken into account.  If you need to upgrade computer software, or train call centre staff in the delivery of a service then this all needs to be taken into account.   If things change and are not taken into account then much future action may be outside the scope of the contract.  Worse, there is potential that your products and IP are not being protected or that you have your eyes on the wrong ball.  Traditionally, lawyers would insert a general statement to say that you own something now and forever in the future.  But what if your product has changed so much that the thing you’re delivering is no longer within the scope of your original contract? How do you define or negotiate on the basis of detailed subtleties?


I work around this by specifying the relationships as part of the contract construction and the meaning of the terms.  As in our example above, if I am selling Product A to Supplier X and I need to rely on the components then I need to specify both their relationships with Product A and with each other – over time.  I need to specify the state they will be in when they are no longer part of the system.  If I specify the unique operation of the components together then I will know what it is I am protecting.  If I make this part of my delivery processes then I will be able to guard against copyright theft and trademark infringements.


The Process View shows the client’s preferred operating model and service delivery scheme.  Once again, it is not simply the processes themselves which need to be specified but how the processes interact and their dependencies which gives the contract its unique flavour.

Most importantly, the processes describe how we are going to manage our business objects over time.  In the process view we match our delivery processes/operating model to the objects.  This is crucial.  A traditional legal drafting view would be to impose a ‘we own everything ad infinitum’ perspective.  However, if you know how your stuff/services are going to be used you can give lesser elements away as negotiating collateral.  You can negotiate and contract with precision and fine distinction that manoeuvring into your preferred contract become less art and more science.  You also now understand what will trigger management action, what elements of the contract need to have embedded links to the contract management/procurement/financing etc.  The process view lets you define exactly how you intend to control your IP collateral and assess the actions of your partners and suppliers.


The Implementation View holds the actual contract clauses.  This is where the ‘rubber hits the road’.  In this view we take the information from the other 3 views and blend them together to build each clause.  We take the structure of all our business objects, ensure they have the right relationships the client wants (and they are correct over time) and we make sure they are accounted for in the operating model and any service delivery processes.  More importantly, the clauses are derived from and traced directly back to the technical and business architectures.  You now own your contract and you know exactly what it does and how it takes care of you.

In summ, if we have focused on the business objects and not just the law then we are in a better position to control how our products and services are used.  We won’t need to be heavy handed with our customers and stifle our communication and stunt our growth.  An architectural process not only allows us to contract in a faster, more precise way, it also integrates the business allowing greater analysis of dependencies, impacts and trade offs.  In short, such a contract design framework represents practical steps towards a business driven, seamless end-to-end architectural process.

How Integrated Contract Lifecycle Management Can Reduce Legal Fees 1


In a recent study by the American Bar 58% of procurement departments noted that they had been involved in purchasing legal services for three or more years.  More than half the respondents were Fortune 1000 companies and about a third were Fortune 100.

Despite this trend most legal work is neither panel-based nor subject to competitive reverse-auction processes.  In fact, back in 2007 McKinsey Quarterly ran an article titled “Inventing the 21st Century Purchasing Organization.”  They noted that businesses had woken up to the cost benefits of strategic sourcing and intelligent supply and management.

It is my prediction that with the massive oversupply of law students and as more lawyers move out of the profession into traditionally non-aligned areas our age will see a large rise in the need for law firms to become highly competitive.

The American Bar reported an interview with the Chief Procurement Officer of a large company.  He stated that “if you know your business, you should know how long something takes and how much something should cost”.  He had worked in the nuclear power industry and thought that building nuclear power plants was a lot more complex than litigation.  Understandable, although I should add that in most industries (Defence excluded) there is no one on the other side conspiring to destroy your plans.  Needless to say, he has a point.  Most law firms track costs but they don’t track work.  They track bills but they don’t track customer value.  Legal work suffers from a dire lack of transparency largely because it doesn’t need to.  In the legal profession it does no one any good to try and commoditise their work.  However, that’s exactly what needs to happen.  In many areas the rise of the paralegal (e.g. conveyancing) has been aimed at increasing profit margin internally rather than increasing customer value externally.

In order to increase customer value to corporate clients law firms must integrate their services with the company’s business lifecyle.  When this occurs the results will likely decrease total legal spending per project but they will likely increase the total number of projects using external legal assistance.  Why?  for the same reason iTunes didn’t decrease the per capita spend of teenagers on music.  Integrate with their life style.  Give them more opportunities to spend.  With a clear idea of the value external counsel can offer on a specific deal or project and the ability to keep the legal spend down it is likely that managers will seek to use that new found power to cover themselves rather than have their own accounts and reputations wear the risk.  The effect on total law firm revenue should be negligible but the effect on law firm structure should be striking.  As the commercial legal sector strives to accommodate the need for increased throughput there will likely be a greater emphasis on workflow and process.

The graph above outlines (in red) the traditional legal spend.  Very high costs being injected at pre-determined points of the business lifecycle.  This does not take into consideration all the costs which are incurred from failed contracts and poor contract management.  The blue graph outlines the standard curve from contract management expenses.  Current contract management professionals are involved earlier in the business lifecycle.  Where problems arise of specialist legal expertise is involved then external counsel are involved.

Gartner note that in 75% of the contracts they review they find hard dollar savings.  As markets develop and try to develop new revenue models through licensing options and new pricing structures it is vital that the operational parts of the business remain up to speed.

Law firms are very important and they are not going away.  The depth of knowledge they provide and the expertise in navigating transactions, deals and disputes cannot be delivered through new software.  The trick, however, is to  maximise the value for money from law firms.  The best way to achieve value for money is to ensure that detailed legal advice or drafting is injected at the precise point of value from the most valuable person and this is where intelligent procurement will have the most impact.

Most importantly, legal advice and transactional support is not operational. There are very few lawyers in very few sectors who have operational awareness let alone operational experience.  This is where professional contract managers can have the most impact.  By detecting risk in the subtleties and complexities of operational and technical minutiae contracts professionals can have a huge impact.  The company is likely to spend less on legals as well as making it a far wiser and effective spend than now.

What does this say about contract management today?  Contract management is by and large an ineffectual and redundant function.  Sandwiched between project management, operations and legal – and adding little value to any of them – one has to ask what the point is?

What does effective, integrated contract management look like?  It would mean that once operational problems were detected and identified then analysed the contract managers would be able to determine the precise level of legal exposure.  This would require the contract management function to be able to analyse financial, operational and technical issues within contracts and assess them for validity, severity and impact (including probability).  The contract managers are then empowered to assist the business to deal with these problems.  This is not the contracts and commercial departments of today.

The contract management function described above requires a variety of monitoring systems:  From the top down, the business needs to analyse cost structures and EBIT for risks before variances arise.   From the bottom up, the CRM systems need to percolate a wide variety of issues which line managers can analyse for veracity, velocity and trend.

Identifying issues as potential contract problems is NOT the job of most line managers.  The contract professional has that job with the assistance of the program manager/account manager but acting together in an integrated business lifecycle a modern contract management function has the ability to reduce risks and legal spend significantly.

Risk Cascades: Managing Financial Exposure from 3rd Party Contract Risk Reply


In an October 2009 article in McKinsey Quarterly the authors Eric Lamarre and Martin Pergler outline how indirect risk is the key to reducing net residual risk.

Net residual risk is the risk a business is left with after they have dealt with all the obvious risks.  For instance, obvious product liability, insurances for warranties and even hedges for currency or commodity price volatility. Net residual risk of over 30% is often standard for ICT contracts (scope creep, unforeseen faults etc).

Significantly, net residual risk is hidden risk.  More importantly, hidden risks can sink deals and kill companies because not only is the risk uninsured (financially or operationally) its unforeseen nature means that surprise brings with it increased cost and severity (i.e, by the time it percolates to the top it has already boiled over into a significant issue).

The fact of the matter is that indirect risk creates potentially huge financial exposure.  It does so because indirect risk cascades.  Indirect risk is exponential in its nature because it cascades through an organisation or throughout a contractual network.  As each party adds its own risk premiums to a cost which has a hidden risk, it aggregates in a non-linear way.  The resulting overall exposure can be huge.

Take, for instance XYZ Parts Inc. have a manufacturing contract for making Widget X as part of a navy submarineThe widget is made to the wrong dimensions. XYZ Parts is liable but has no way of paying and their insurance is minuscule and will not cover the liability.  As this risk has cascaded throughout the contract network it has aggregated exponentially to create huge financial exposure to the Prime.  The diagram below shows how this happens.

In a recent CFO survey (CFO magazine, “Working Well Together:  managing third party risk in a more integrated world) CFO magazine came up with some surprising results, namely:

  •   Fewer than 50% of CFOs thought their company had well defined processes for dealing with third party risk, however
  • 38% noted that third party risk identification and visibility is one of their top 3 priorities, and
  •   roughly 75% responded that a third party had harmed their business in some way.

Pegler and Lamarre note that the likely causes are due to (a) lack of senior executive involvement in enterprise risk management, and (b) poor and disconnected risk management practices.

In a recent brochure I outlined one way to manage third party risk.  It is very difficult to develop operational procedures to deal with contingent risk.  Corporate feudalism dictates that identifying risk and stepping in to another division (or company)  to deal with it is complicated.  Firstly, in the opaque and murky world of rivalries between companies or divisions in a contractual network the risks need to be identified architecturally.  The architecture (engineering or ICT) is the only aspect that is transparent.  Only by using central models can all parties identify risks which impact their business.  Secondly, contingent risks can be ‘sold’ to other companies in the network (through, for instance, put or call options in the contract).  In this way, an internal hedge market is created for dealing with third party risk).  This is a far better way of dealing with significant indirect risks as ultimately it engages the powerful finance function and creates huge inducements to contractual performance (such as wholesale loss of intellectual property).

Regardless of how risk is managed most senior executives agree that in our modern, interconnected world it is no longer sufficient to leave third party risk to chance or to blanket boilerplate of standard contract clauses.  If companies are to reduce financial exposure from third parties risk must be hunted down and dealt with; specifically and in detail.

What is “Anti-Law” – Pt 1 Reply

I define anti-law as the means of producing legally binding outcomes through the use of non-legal methods.  Lawyers would argue that this is the area of Equity but Equity is a poor cousin to anti-law.  Where in Equity there would largely go towards intent, there would be little design.  In anti-law, there is both intent and very precise design.  


Technically, anti-law would be the opposite of law but one can see I am using some poetic license.  I came up with the notion of anti-law when I found it hard to describe what it is I do.  I felt it somewhat inaccurate to say that I just drafted contracts using a different method.  They’re not contracts of the ordinary ilk and they are not really drafted.  Would I be quibbling over semantics to say that I ‘architected the preferred operating model of an enterprise into a legally binding agreement’?  I don’t think so.  Although any lawyer could argue the point so too could two people argue that a Waterford crystal champagne flute and the twisted coffee mug my four year old daughter made in art class are both ‘receptacles for drinking liquids’.  The differences are palpable and the drawbacks in legal definitions are obvious.


Anti-law is then the use of enterprise (or domain, to be precise) architecture frameworks to extend the architectural process to include the commercial solution.  It is where the beauty of the technical solution meets the harsh reality of the business’ operating model.  The elegance is in combining the two in a single, seamless architecture (and indeed the goal of The Citadel Project).


The next question is why?  Why come up with anti-law? Why not just do better drafting.  The answer, like our cups, is that standard legal methods are incapable of dealing with complexity.  In short, the adversarial system (and legal positivism) is in direct conflict with the ontological reality of how things/matters/projects/capabilities change over time.  Where the latter deals with complexity over time, the former takes a narrow, local view.  This is not a small problem.  In positivist terms, where a thing changes over time, is it a new thing?  So we can see the issues of changes and variances in contracts.  In ontological terms, the thing is the same thing, it just morphs.  It does, however, retain the same identity and unity.


Some might say that it’s an outrageous statement to argue that contracts don’t deal with complexity.  They must?  Look at the lack of litigation in the outsourcing and Defence procurement areas.  Just as the lack of fighting is a poor indicator of friendship so too is the lack of litigation a good measure of the accomplishments of the intended operating model.  Don’t forget that this lack of litigation often continues through years of poor performance.  It would be poignant to ask what the point of the contract was in the first place?  On the other hand, in the building and construction industry where the complexity is just as great but time and cost are more critical (to each business) one sees that litigation is rife and commercial ruthlessness is the default.


In order to deal with complexity in a precise way and a way which allows the contract to adapt over time with the complexity of the evolving threat/business environment/project/capability – the key component is time.  Architecting such an organic contract cannot simply be a true reflection of the ‘business’ at any given time – a snapshot – it must actually be the business operating model. 


Cash is king.  A common business saying but never a truer phrase has been spoken in the commercial world.  Just as all roads lead to Rome so too must all commercial ideas and methods lead to this single commercial outcome – cash flow.  Architecting an organic contract not only assures the developing program but the revenue is also assured.  It is the revenue model which must be guarded and variances which affect it must be dealt with.  

How to architect a complex and evolving contract is dealt with in Pt. 2