Month: July 2012

The Resource Allocation Collaboration Architecture

It's a well worn and cynical observation – that I use often – but it's worth repeating. A “process” is something you'd like other people to follow in situations where you yourself would just use your own judgment. A “framework” is what you think other people need to understand in order for you to do your job correctly.

The way we manage our organisations is filled with these sorts of half solutions. In particular, it's filled with ways of managing complexity that put obligations on others. Putting it another way, the application of the method differs depending on what side you're on – us or them. “They should follow a better process”. “They don't understand our framework”.

Enterprise Architecture is a good example of this. It's locked in a battle with the upper echelons of the corporate world. The premise of enterprise architecture is that you can make systematic decisions about strategy and resource allocation based on building an integrated model of the business, information, applications, and infrastructure (or any number of different layerings and groupings).

Enterprise Architecture (EA) competes with general management and governance principles which align decision making rights with responsibility – regardless of the availability of enterprise architecture models or frameworks. In this context EA could be accused of wanting to eat the cake (of strategic thinking) but not wanting to accept responsibility for the consequences (the fat of being the decision maker).

The problem of creating a systematic approach to strategic resource allocation is a real and important. It deserves to be solved for your organisation. However, it's not a modeling problem, it's a collaboration problem.

I like to talk in terms of “Collaboration Architectures” – this is a sort of “applied architecture” discipline which simply defines the architecture as a “delimited shared understanding”. It's descriptive of the shared understanding of the components, layers, and relationships that the group collaborating all agree on. Most importantly, that delineated shared understand only changes organically with the understanding of the group. You find the collaboration architecture before you change it.

These collaboration architectures are the bridge between soft skills, general management principles and governance, and the desire for systematic approaches to management. It's only in relation to this type of architecture that decisions can be make (including allocation of tasks, resources, performance management, etc).

Collaboration architectures can be mentored by a third party – just like individual meetings can be facilitated or chaired – so there is no conflict of interest between who owns decision rights and who is mentoring the collaboration architecture.

If Enterprise Architecture is to be saved from obscurity – or at least from being constantly misunderstood as it fails to define itself consistently – it needs to focus on the how it facilitates collaboration. It also needs to be clear on what decisions its collaboration architecture supports.

A collaboration architecture for executives coming together to make resource allocation and strategy decisions is powerful. When enterprise architecture plays this role it to is a powerful strategic tool. But it needs to loose a lot of baggage lest it be replaced by other collaboration architectures more suitable to the task.

But that's for another day…

Is Your Management Team a Cartel?

You likely have an understanding of what a cartel is, and know some historic and contemporary examples – collusion on price in the international shipping industry, gold cartels, and the diamond cartel – all alleged, of course.

Cartels simply agree when they should be competing. Those who support “cartel busting” do so because they believe agreeing when you should be competing breaks the competitive processes that make capitalism good for consumers. It reduces choice and keeps prices artificially high.

While the benefits of capitalism may not be universally accepted, those arguments only make the following analogy more interesting:

What is a cartel really? It’s a group of people that sit around, don’t like to write anything down, and agree on the value of something. Also, they agree on the value of things based on their own interests rather than letting market forces decide.

Is this not precisely what your management team is there to do? Isn’t your management team in that case rather like a cartel?

This isn’t a problem in itself. You need a management team (right?). Otherwise you are admitting your organisation’s aggregation of services, directed by your management team, has no chance of delivering value beyond what your customers could source themselves via a number of coordinated transactions on the market.

The problem isn’t that your management team is like a cartel. The problem is not acknowledging the market-like processes within your organisation that are bypassed when a management team simply “agree amongst themselves” on the value of something. The problem is seeing your organisation only as a governance structure and not seeing the internal market.

The more a management team struggle to “get along” or “be a strong team” the more they loose touch with clients, markets, and employees. How many times have you heard about the need for a “strong management team”? In contrast, how rarely does your management team get pushed internal “market indicators” that they can’t control, or that haven’t been filtered for their consumption?

The problem isn’t the management team agreeing, the problem is the management team agreeing too readily, without sufficient evidence, or without sufficient engagement with the organisation as a whole. In other words, without being linked with the internal market of value within the organisation.

Wherever side of the economic arguments you might sit on – the Austrian economists, for example, don’t have an issue with cartels – the idea of busting cartels is exciting. If you want to bust your management team cartel, the tool of choice is information.

Real cartels bypass the market, bypass the price system. The problem is that organisations don’t even have a price system. They have financial accounting systems, but they only cover a very small proportion of the internal market and are often too readily manipulated and “gamed” by the management team.

In fact, your management team exists in lieu of a price system. That’s almost the very nature of a firm. But the nature of firms is changing. Social media technologies, direct communication channels, and alternative organisational structures such as communities of practice, broadly open the information channels within and across organisations. When this happens the flow and valuation of information become a sort of price system.

While I might once have suggested organisations could benefit from introducing a price system, I believe the tide has turned and it’s now just as important to ensure the management process is re-engaged with this information-based price system that already exists. Not to be driven by it, but to ensure it both informs decision-making and supports the implementation of decisions.

All of our information systems – when implemented with this explicit purpose – can provide a view of this internal market. They can all be viewed as part of this price system. Every activity brokered through an information system can be viewed as a transaction in a market that contributes to one or more market indicators.

Busting your management team cartel is reconnecting with this internal information market. What steps might you take to ensure that your management team isn’t acting like a cartel?

  • ensure the management team is presented with external information, that they didn’t generate themselves or that wasn’t directly generated for their consumption.
  • ensure the information used to make decisions is shared across the organisation when possible. This uses the internal market to value the information used in decision making.
  • Openly compete within the management team. Any management team, particularly one structured across functional lines, has a fundamental conflict of interest regarding which function gets the most resources. If the management team isn’t arguing about resource allocation they aren’t trying to optimise their respective functions.
  • Don’t compete. The specific structure of the management team is important. If the organisation’s strengths and weaknesses are understood and agreed within the management team then some roles within the management team are more difficult than others. There are allowed to be “losers”. Some regions are more competitive, some functions are first to struggle when external conditions change. A rich model of the organisation’s operating model should inform the management team’s decisions.

So go cartel busting. If your management team is used to making decisions by simply agreeing amongst yourselves – with little reference to information not explicitly produced for consumption by your team – you may be acting like a cartel, and your consumers, the whole organisation that depends on your services, may be suffering.

 

 

Your Organisation – Thinking, Fast and Slow

In his bestselling “Thinking, Fast and Slow”, Nobel Prize winner in Economics Daniel Kahneman proposes a model for human thought based on two systems of thinking. “System 1” is defined as fast, instinctive and emotional. Whereas “System 2” is slow, deliberative, and more logical.

Most importantly, “System 2” is lazy and doesn’t even bother showing up to the thinking process unless it has too. In reference to study after study, Kahneman builds a case that people tend to make intuitive decisions, based only on the information available. They use “System 1” because “System 2” is hard – when you use “System 2” you can feel the strain of thinking.

What’s more, when “System 1” is used to make decisions we are confident of the answer even when a lack of evidence exists. They are typically internally consistent decisions based on a number of heuristics that make thinking easier – i.e. less mental strain. Never does “System 1” seek out additional information.

Kahneman proposes that “System 1” operates in What You See Is All There Is (WYSIATI) mode. When asked to answer a question people tend not to incorporate information that isn’t already right in front of them. They rarely think about the sort of information they would require to make an effective decision; but rather think of what decision can be made with the information they have.

As information management consultants, this “System 1” / “System 2” model of thinking about how individuals made decisions can be applied to organisations as a whole.

“System 1” is the way decisions are made with no explicit investment in information management. “System 2” takes more effort, because it must begin with an investment in understanding the information assets you have, the decisions you need to make, and whether there is sufficient available evidence to make an effective decision.

General management devotees make a great fuss about the importance of being decisive – in making the best decision with the available information. And there is certainly value in this approach where no alternative exists. But an alternative does exist.

Creating a systemic approach to delivering the right information, to the right people, to make the critical decisions at the heart of your operating model, is making an investment to build a “System 2” thought process for your organisation. It might be hard work – you’ll feel the strain of thinking – but it’s worthwhile.

Thoughts on the MWT Competency Centre

I’ve been thinking through the idea of a competency centre this evening. This is mainly because I’m supposed to be thinking about it for work but never get a chance. Interestingly I think it’s a powerful concept and might actually help with the implementation of MWT models.

One of the reasons I think making a market-based management model isn’t intuative to most organisations is that it requires the combination of a number of disiplines that are usually kept seperate. These are the same disiplines that I’ve always tried to bring together so it makes sense that it would be posible to view it this way.

In particular, I’ve always fought for “business processes” and “information” to be viewed as peer rather than “business proceses” need to be considered first. This comes from work in deep technical IT land for a number of years and recognising that there was nothing particularly primary about looking at business proceses. You were in fact just as likely to get bogged down in the detail of business processes as you were to get bogged down in the detail of any other part of the analysis.

Similiarly, I’ve always disliked the distinction between “management” and “technology”. I hate the phrase “I’m not a technical person” because I have no idea what that means and I suspect it usually means “I don’t understand” or “I’m too important for this”. Throughout the MWT model I also promote a view that says “management is a technology” in that it is a specific set of tools that you actually have to use in order to them to do anything. Similiarly, the “I’m not a technical person” comment ignores the fact the management is a disipline riddled with jargon, acronyms, secret language, and specalised knowledge – all the things that make “technical” what it is.

So, I’ve made another cut of what the MWT model combines. In general any market-based management approach probably combines these disiplines.

 NewImage

Powered by WordPress & Theme by Anders Norén