In a recent blog Richard Sage (@BakedIdea) points out that governance is just a matter of openness and sharing. If only life were so simple. If this were the case then what of Enron? What of the whole global financial crisis? These people were open? These people shared? They had GAAP reporting duties – So what went wrong?
The simple fact of the matter is that (i) governance is more than just sharing, but (ii) less than the full apparatus of conformance which Richard sets out.
More Than Sharing
Governance is more than sharing. It is about design and flow. Financial institutions shared information internally and reported it externally but this made not one jot of difference to the near collapse of the global economy. Collateralised Debt Obligations (CDOs) were so complex that it would take a long time to unpick each one. It is essential to understand that if an organisation actively conspires to confound regulatory procedures then there is no governance structure that will catch it.
“Governance without design is somewhat akin to looking at a ball of multi-coloured string and trying to guess what the pullover will look like.”
Organisations (here I extend the net to government and not-for-profit) need to design for misuse. Understand that cross-functional information flows require some degree of architecture. Without the necessary degree of design in governable artefacts (e.g. cost models, delivery schedules and contracts) it is impossible to unpick them. In fact, it is somewhat akin to looking at a ball of multi-coloured string and guessing what the pullover is going to look like.
Governance Is Less Than You Think
I believe that governance is only the set of structures necessary to give confidence to institutional shareholders that their interests are being well looked after. The functions are the business processes and technical systems which enforce and deliver them. This is why corporate governance speaks only of Directors Duties and not of business process. The how will be forever changing in our modern and dynamic world.
In the end, governance is counterintuitive to business. Good governance is seen to reduce profits, to close off avenues of growth and to burden management with bureaucracy and nugatory process. Yet good governance should clear the way. It should lower the bar and reduce the hurdles. In concert with a stringent and effective assurance process governance becomes light yet effective. It delivers confidence without suffocating the organisation.
Social media part 3: leveraging social media data analytics to improve M&A – Lexology.
There is no question that social media has a role to play in M&A activity. In a recent survey by Toronto based international law firm Fasken Martineau; respondents reported that they were not only using social media to communicate deals but also for research and due diligence .
- 36% for research.
- 48% for investigation.
- 72% like LinkedIn to research personalities. Only 50% said the same of Facebook.
- 78% disclose transactions through Facebook and 44% use LinkedIn.
- 77% said they have no social media strategy, and
- 65% said they have no intention of developing one.
DATA v SENTIMENT
There are 2 benefits of social media: (i) expert opinion, and (ii) trending sentiment. Much of the hype behind the trends in Big Data are about connecting these 2 powerful elements with the hard numbers around corporate valuations. For instance, an acquirer may wish balance valuations with the trending market sentiment and the opinions of experts. An extreme example of this is the Facebook IPO where market hype vastly outweighed traditional valuations. So much so that Warren Buffet said that he had no idea how the valuation was so high and that he just couldn’t value companies like this. Social media is often seen as an echo chamber; a small community talking to itself. Posts range from self-aggrandisement to advertising puffery with very few hard facts and figures in between. What few figures are there may be real, may be fictional or may be somewhere in between. The value is in aggregating these figures but the algorithms needed to ensure that the right weighting is placed against the right number based on author, time etc (let alone how they account for hearsay). the maths behind this is hard enough let alone the semantic interpretation by computers. Needless to say, when this sort of calculating can be done it will be worthwhile for many and will be, initially, a very, very expensive service.
The moral of the story is – BEWARE!
Social media remains useful for advertising and developing an extended network of sector contacts in order to deepen one’s contextual market knowledge. However, as an analytical tool, to my mind, it is still out there with witchcraft.
Good financial risk management requires a high level team team effort and cross-functional collaboration. Risks, by their very nature, are highlighted precisely for the reason that the project team is unable to do anything about them. If they could be effectively mitigated or avoided by a single function (e.g. Legal, Finance, Operations etc) then they would/should not have been placed on a Risk Register.
“If the project were able to mitigate the risk themselves, alone, then it wouldn’t be a risk.“
Dealing with these risks, therefore, requires not only close collaboration from multiple functions but it also requires the delegation and intervention from pay-bands which are at a higher level than the project, i.e. effective management of financial risk is expensive. The corollary is that project teams should ensure that whatever risks they have identified are very important and cannot be dealt with by the project team.
WHAT DO BUSINESSES USUALLY DO?
Traditionally, risks that populate project risk registers will be well-known risks. To be unkind, these will be statements of the blindingly obvious. A menagerie of opinion, Google hits, speculation and wild guesses. In the absence of an external assurance function, risk managers work for Bid Managers or project teams. They are not incentivised to look too hard or too deeply at risk. The last thing that either of these roles want is prying executive eyes or torches shined into dark and dusty corners of the business.
“Most risk registers are populated with a menagerie of opinion, Google hits, speculation and wild guesses.“
Future blogs will go into this area in greater depth. However, in the absence of an external assurance function curious risk managers can assuage their intellectual integrity as well as supporting their boss by deriving their risks statistically. By going back through 6-10 similar projects they can analyse, categorise and classify risks by a variety of quantitative and qualitative measures. In this way, the Risk Manager will bring cross-functional experience to the project team and, hopefully, become a catalyst for inexpensive, collaborative risk management.
In a recent article in online magazine CIO & Leader Chris Potts argues that technology has come so far that CIOs need to start to take the lead and help businesses move beyond the antiquated structures of yesterday. He says that CIOs need to tell a story of how the business could be, how it should be. He says that CIOs are uniquely equipped with the technological mindset to tell the story of the business of the future.
In recent tweet I was harsh on Chris but in hindsight I believe I need to be more brutal. The world does not go round for a lack of dreams. Businesses are not short on vision. What is lacking is execution. Projects do not fail for want of strategic intent, they fail for want of expert systems engineering and expertise in engineering systems. This means that an enterprise doesn’t only need good technical expertise in their horizontal functions but they need expertise in the methodology which carries that knowledge as it passes through the market verticals. This is to say that it is fine to be a good project manager but can you manage the project from market analysis through to business development? Can you manage the project through the architecture? Through to contract close out?
None of this relies on telling stories. These is deep technical expertise. Storytelling shouldn’t be ignored. One of my all-time favourite authors, Larry Prusak, is a huge believer in storytelling as a means for engagement and building up a common picture of knowledge. A sort of inherited reference point for change. As important as storytelling is, it is becoming a fad and a distraction for executives. By focusing on storytelling they are ignoring the real complexity hidden in projects.
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Corporate storytelling is developing a huge following and it’s not just for CIOs. Larry Prusak loves it, Patrick Lencioni has elevated it into a fine art and everyone seems to be getting the storytelling bug. Stories are great because they help people from disparate backgrounds develop a common understanding of a problem or vision – one that sticks. Storytelling has the power to corral even the most difficult of us and motivate us to play our part in the corporate journey.
Executives love stories because they require almost no detail, no plan, no roles and responsibilities and no changes in remuneration. Done well, they can convince people into delivering more for less pay and when they don’t stories will shame those same underpaid workers into delivering the goods. What’s not to like about storytelling?
At large UK outsourcing establishment there was an underperforming account in the Midlands. Legend has it that the CEO of the local authority berated the account manager with the legendary phrase: I’ll buy more IT when you can solve teenage pregnancy!” The account manager duly skulked into the corner and got on about his job of providing outsourced IT services. What should he have done? He should have used that story to develop truly value adding services which would have (i) increased the profitability of the account, (ii) built trust between him and the CEO, and (iii) possibly helped try and solve the actual problem.
He didn’t, so I did. I went to India and spoke to our outsourcing partners. I tried to engineer an end-to-end process whereby we could harness the incredible intellectual latency of our outsourcing partners, Genpact and Patni, to develop an integrated process for analysing local authority data then identify and target girls at risk for tailored social services. In this way we could break the socially debilitating cycle of early teenage pregnancy whilst pushing account revenue into the stratosphere. We needed to do this in a way that enabled us to retain the confidence of our customers as well as created buy-in from internal management. So, we made sure the data security was right and that the project was aligned to the new corporate strategy of a greater push into outsourcing the middle-office.
I told the story. I told it again and again but I used it to tease out the detail of the development process, the customer engagement process, the revenue model and the customer benefits. Because, for every executive who smiled at the heart-warming vision there were 3 contrary developers, engineers and other middle managers who tried to shoot me down with the detail. My story explained the engineering process. My story was the glue which pulled all the systems engineering together and that is how I believe enterprise storytelling can help organisations.
The IACCM rightly points out that key supplier relationships underpinned by robust and comprehensible contracts are essential to the implementation of significant strategic change. Their research identifies a 9.2% impact on bottom line from contract weakness. Top 5 causes being:
- Disagreement over contract scope,
- Weaknesses in contract change management,
- Performance failures due to over commitment,
- Performance issues due to disagreement over what was committed,
- Inappropriate contract structures or responsibilities.
Two things are given in this mess: (i) Firstly, that contractual structures are weak and inappropriate to deal with high levels of operational complexity and technical risk, and (ii) secondly, that legal means of enforcement are cumbersome, expensive and ineffective.
That business is ready to solve this legal problem by contracting for outcomes is (a) nonsense and (b) missing the point. Business is already dealing with the operational and technical risk of large and complex contracts. Business is already structuring many of its agreements to deal with outcomes. Large prime contracts, alliance contracts and performance-based contracts are already commonplace in PFI/PPP and Defence sector deals. That neither are wholly efficient or effective is for another time. It is, however, for the legal community to devise more sophisticated ways of contracting in order to solve their side of the problem.
PEOPLE ARE THE KEY
The primary reason for not being able to contract for outcomes is that the vendor doesn’t own the people. This is critical because without the ability to control and intervene in the delivery of work the risk increases exponentially. Consequently, the risk premium paid for outcome-based contracts will either make them (a) prohibitively expensive, or (b) impossible to perform (within parameters). So, a business which offers you an outcome-based contract is either having you on or just about to charge you the earth.
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:
- The BA derives the Business Process Use Cases from the analysis of process documents.
- The BA then works with the business to devise ‘realisations’ of these use cases.
- The realisations are then analysed for System Use Cases.
- The system analyst (SA) then works with the tech teams to design system realisations which instantiate the system use cases.
- 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.
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?
The chart below only serves to prove Paul Strassman’s mantra that outsourcing is more an emetic than a cure. By and large the following is true:
- Outsourcing is a financial decision and not a business one.
- Companies engaging in heavy outsourcing activity are overall commercial losers.
- Financial gains from outsourcing are usually mythical as per user costs usually increase from declines in overall employment.
- The only financial gains from outsourcing are usually short term wins on the stock markets.
Large scale outsourcing of the IT function weakens corporate productivity by lessening flexibility at a time where the company must create additional agility in order to survive. The heavier the outsourcing activity the more likely the business is to lose its information management function, i.e. the ability access information (which now largely resides under vendor SLAs), package and use it quickly and effectively is now gone.
The secret to IT outsourcing is to (a) commoditised and (b) focus on capability. Firstly, businesses should not even have to think about infrastructure. There are very few arguments to retaining one’s own data centre. IT infrastructure and even network monitoring and optimisation are highly commoditised product offerings with very low risk. Just do it.
Secondly, focus on capability. Understand where technology creates value in your business. Focus on increasing the productivity (and reducing costs) of those areas of opportunity by packaging modular information offerings from high-end suppliers. For instance, some outsourcing companies specialise in data analytics and BI. Some specialise in risk analysis and some specialise in service-based client messaging. Start to build these services – all of which can be done better and cheaper by outsourcing firms – and begin to build them into a client narrative which allows your business to penetrate deeper into the middle and front offices. This is just an example but it highlights the fact that if your company has a modular information supply chain you have the agility to create great, differentiated service offering based on real customer value.
Be careful what you outsource. Get to grips with business complexity (it’s here to stay) and don’t derogate from your business responsibility to information management.
Aristotle wrote that “metaphor is the worst form of argument. He’s right. If you have something to show/prove, then do so precisely and in a way which is meaningful and useful to your target audience.
Recently the guys at Innovation of Risk posted an article on the use of infographics to analyse risk. I don’t know who coined the term “PowerPoint Engineering” but most infographics fit neatly into this category. Infographics can save presentation or they can sink it but mostly they are used to convey ill conceived and poorly thought out ideas which snowball into worse run projects. The best advice is to take these bath-tub moments (why do people think they have great ideas when they’re washing?) and run the analysis with an expert using an expert system. If you can’t do that then (a) you’re in the wrong department for having the idea in the first place, and (b) chances are that there is a tonne of minute but important detail you missed out.
Whilst I think that visual display of graphics is vital to achieve stakeholder buy-in, it is also clear that imprecise PPT-engineering masquerading as infographics is the worst form of management snake-oil there is. An erstwhile systems engineering mentor of mine used to say, “if you think they’re BS’ing you then ask them what the arrows mean”. 9 times out of 10 they won’t have a clue.