Author: mdegeorge Page 18 of 21

Matthew De George is a well respected management consultant focused on technology-enabled business transformation. He typically wont tell you what your strategy should be. But he'll "get it", and he'll help you execute. Matthew brings 20 years of experience in transforming business and customer-facing processes through the effective implementation of technology and information management practices.

IT Outsourcing – How to avoid it or make it work for you

I often read a lot of bitter comments on news articles – such as this one – when a new IT outsourcing arrangement hits the press.  The reader comments often appear to miss the whole point of outsourcing and in turn what could have been done to avoid it.  I’ve always taken the approach the IT Outsourcing has value, isn’t in any way morally wrong, and is here to stay – so I’ve eventually learnt to understand it and therefore understand the opportunities in the industry.

Firstly, it’s important to understand that almost all cost savings provided by outsourcing are through increased visibility of spend and therefore more careful selection of which initiatives are pursued.  It may be that certain outsourcing relationships offer access to specific capabilities, or that certain outsourcing relationships can be managed as a source of differentiation or innovation.  But that’s not generally the value of outsourcing; that’s just outsourcing as a pillar to strategy and innovation management.

Outsourcing is often a last ditch effort to get costs – or visibility of costs – under control.  It’s a recognition that portfolio management processes aren’t working, nobody fills out their timesheets, it’s very difficult to get IT departments to think in terms of business services or capabilities, it’s very hard to ensure documentation is kept up-to-date, and in general that mismanagement of IT has burnt out IT resources.

Outsourcing solves a number of these problems by simply putting a contract process in the middle of everything.  Outsourcing basically means that in order to get anything done you need to procure a service – which means you have to justify the spend, assign it to cost codes, and be clear about the outcomes right up front.  All of these things can be achieved without outsourcing but they simply aren’t.  There isn’t enough discipline to do things consistently so the management team simply can’t run the IT department ‘like a business’ because they don’t know what is going on.

By putting a procurement process in the middle of everything it forces proper allocation of costs for everything.  The outsourcing partner gets to choose between doing things for free, or being paid for it and thereby having to commit to certain outcomes and to be part of a managed procurement process which gives visibility of spend.  Eventually, outsourcing partners decide they want to get paid for services.  Eventually, things get better…

Unfortunately, being able to come to a contractual arrangement, to actually procure services, is a capability of the client organisation.  It requires an ability to define outcomes, to cost and transfer risks as appropriate, and to perform service definition and orchestration.  At the new finer granularity of the services to be procured the client organisation that has just outsourced may not have these capabilities.

So outsourcing arrangements suffer from an inability to come to contractual arrangements.  And the reason they do is that they have never had to do those sort of contractual arrangements before.  All of the portfolio management disciplines, solution and enterprise architecture processes, cost allocation, and even basic IT strategy process, haven’t been working.  The fact that they weren’t working is the very reason the outsourcing had to occur.  But they are still required in order to come to contract agreements once outsourcing is in place.

A common mistake is to try and roll-back the disipline in coming to contractual agreements.  Because the supporting capabilities aren’t in place it’s very time consuming to come to agreements.  The cost of spend visibility is seen as too high.  But rolling back the requirements to come to contractual arrangements shouldn’t be the solution.  Also, the contractual arrangements also allow the flexibility to procure ‘outcomes’ once the diciplines are in place to know what outcomes you actually want to procure.

In theory, you can avoid outsourcing by putting certain things in place to ensure full visibility of costs to the executive team.  In theory, you can implement all of the portfolio management processes, enterprise architecture processes, cost allocation, etc and avoid the need to outsource at all.  But in practice you can’t because there will always be comparative advantages in different countries / regions, and advances in communication and collaboration technologies that make off-shoring a valuable strategy.  And while your company could build their own off-shore capabilities there are political and cultural  considerations that make this a risky strategy.  To off-shore you generally need to outsource.

So in the end, outsourcing is here to stay.  The only thing you can do is understand how it delivers value so that you can understand how work is different in an outsourced environment.  Here, the key messages to the ‘retained organisation’ are: things will change, new people will not have the same experience with your systems, new people will take longer as first.   Most importantly, the message to the retained organisation is that for most people outsourcing isn’t actually for them – outsourcing is for the CFO or CEO.

The key message to outsourcing service provided is simple.  Get much much better at providing the services you have been procured to provide.

There will be a number of new skills that you need to aquire when you first experience outsourcing.  However, it’s worth learning them because this isn’t going away and some of them are skills you may have been missing for a long time.

“We glorified finance, we privileged finance, we even subsidised finance”

ABC radio’s PM programme has a good little interview with Jim Standford regarding how people incorrectly think of economics as part of the finance industry rather than the finance industry being just a part of the economy:

JIM STANFORD: … I mean the financial sector is a part of the economy but it’s not the most important part of the economy. In fact in many ways it has very little to do with what the true economy is about, which is about average people getting up, going to work, producing something useful, a good or a service that has inherent value, and then how we pay people for it and how they buy stuff.

JIM STANFORD: I think that this meltdown in some ways is the culmination of say three decades or so of a trend where we glorified finance, we privileged finance, we even subsidised finance through a tax system that favours paper investments over real production. And we came to equate the ups and downs of the markets with what the real economy was all about and that was wrong.

The financial sector doesn’t produce anything of real value in and of itself. It is supposed to facilitate investment and growth in the real economy but it ended up serving its own purposes. It became the tail that wagged the dog and as a result of 30 years of over-financialisation we had this inevitable breakdown and now we’re all paying the price.

Bad maths, accounting, and risk management

A brief, but interesting introductory article on the types of accounting rules that are legal but which promote bad investment in the long term appears here (pdf).   The summary, in the form of a joke, follows:

 

 Three accountants interview for a job.  When asked to evaluate 2 plus 2, the first responds “four,” and the second, thinking it’s a trick question, says “five.” But the third, whom they hire on the spot, says: “what do you want it to be?” I wasn’t laughing, however, when I learned that the behavior of candidate three lies within generally accepted accounting practice.

 

The article provides an example of the “trouble [that] can arise when single numbers are substituted for distributions.”  But I think there is likely to be a more general explaination of the problem.  Also, as the article sights there is the general problem of: 

 

  …But when they need to estimate the NPV of a project for an accountant, they will inevitably be asked for a number.

 

I can’t help but think this is an example of the ‘bad math’ that Chris Macrae keeps mentioning in his more lucid moments (1, 2, 3) when he say, for example here:

about 10 year ago … in big management consultancies through the 90s I was appalled at a maths error that was systematically devaluing trust, rewarding those who imaged over reality including conflict-makers and short-term speculators -the so called Unseen Wealth Intangibles crisis as it was then called, the Inconvenient Truth crisis as some sustainability mapmakers now call it. (typos corrected from the original quote)

Somewhere in all of this there is a lesson to be learnt from economics and the need to look beyond the short-term to the long-term impacts of the rules within systems.

Cory Doctorow’s ‘Makers’

Cory Doctorow’s new novel ‘Makers’ is being serialised for free.  His books are always enjoyable.  But this one in particular is interesting because it begins with a great description of a market-based organisation as envisioned under the ManageWithoutThem management model and described in the MWT Book.

It describes an organisation that is designed to both employee but also coordinate via market-facing and market-managed individual businesses.  It gets a lot of the cultural and operational elements of this sort of organisation spot on.

I’m currently working with Satyam – which has been in the news a lot this year – and is supposed to be organisd in this market-managed way.  However, I think a lot of the internal processes, and the Indian approach to family-based management of businesses, get in the way of this and often break the model.

Technocracy and Politicisation

I’ve mentioned one of my theories before:

I have a theory that whenever a single specialisation becomes the dominate or controlling specialisation it turns the coordination into a technocracy.  I might be using technocracy in the wrong sense but I’m using it to mean that a single specialisation (i.e. a single branch of technical knowledge) becomes dominate.

It is in this sense that I believe organisations are largely technocratic if they are run by technical specialists called ‘managers’.  In another example, I think this is part of the process that has occured to create the current ‘crisis’ in the financial services industry:

In this case, rather than financial knowledge acting as just one input into decision making, and as just one service available to individuals, financial knowledge became the single dominate knowledge used in decision making.  This in itself was a problem because it interfered with true and proper determination of ‘value’.  But it would also have the effect or corrupting the body of knowledge itself (perhaps not in the textbooks, but ‘in use’).

Eventually, the knowledge of finance not only supersedes all other knowledge, but the finance knowledge actually disappears as it is replaced with what is convenient or beneficial to those in finance.  This process could be a simple as people entering financial jobs even though they have no passion or knowledge of such things because that is where the money is (literally in this case, but it doesn’t have to be that way).

There are two sides to this coin that should be understood.  The fact that control by specialists is the dominant coordinating mechanism in a society (or an organisation) is bad for the society itself. This is basic technocracy.  On the other side of the coin – this control by a particular specialisation is bad for the specialisation.

It’s not that the people who are part of the elite and elevated specialisation don’t have any power.  They do have power, and they can have certain privledges.  However, the actual specialisation itself is hurt.  The knowledge in that specialisation is corrupted.

Not only is the knowledge in the specialisation corrupted, but the group of specialists is itself politicised.  I don’t just mean it becomes a ‘hot topic’ but that it becomes focused on power relationships.  Now I’m not saying anything new if I’m just say that management is political.  Everybody knows this.  But there are deeper, but related impacts of this politicisation process.

In addition to the corruption of knowledge, the politicisation of a group effects the way the group is entered or exited, the amount of diversity tolerated in the group, and ultimately the ability to make non-incremental impovements in performance.

If you understand that open systems (i.e. low political / legal barriers to entry and exit) are good over time, and that diversity is good (again, over time), and that operational innovation is good (if you can even tell when it’s occuring!) then you can see that politicisation is bad for the group and the organisation it supports.

Example from software testing

To use an example that not simply about general management – let’s look at testing.  I’ve spent some time over the years setting up testing capabilities – either for individual projects or across organisations.  I’ve also watched others do the same.  One of the mistakes that is often made during this process is to not hold the testing team to the same standards as developers.

As background, a testing capability provides an independant verification of the software that has been developed, often also ensuring it works with other software developed by other groups.  The purpose of this process is to find issues with the software, but more fundamentally to manage the completeness of the project.

Fundamentally, test management isn’t so-much about finding defects as it is about continuously asking ‘Are we finished?’ and then ‘If we don’t know if we’re finished how can we find out?’ and then ‘Are we finished finding out?’ and then ‘Are we finished?’…

In order control this process there are a number of rules the testing organisation needs to place on developers.  These rules ensure the software doesn’t change in an uncontrolled manner while it’s being tested.  For example:

  • developers should check their own software first, then we’ll check it
  • once the testing team is checking your code, you can’t change it
  • the testing team will tell you if you have to change your code, and we’ll say it was a defect
  • once you fix the defect, you have to check your code again before we check it

These are good rules.  And they work together to provide an element of control and governenace over the software development process.  They provide a gatekeeping mechanism at the end of a project that, if used effectively, will reduce issues with live production systems.  Though the process itself is very expensive (but that’s a different issue).

The problem occurs when the testing team doesn’t hold itself to the same rules.  Examples of this include the case where a defect is raised in error because the test being perform was itself incorrect. This is still a defect – in this case a defect in the test itself – but the testing team doesn’t like to see it that way.

A more subtle version of this is that the defect is never raised but rather the test is changed without a defect being raised.  In this more subtle example the testing team is not holding themselves to the same stardards they hold the development team because they are changing something without a defect.

The testing team sees these decision as ‘saving time’.  But the governance issue is that the testing team are not being ‘tested’.  These means that the testing team have no objective criteria for performance management. They have been elevated above the rules.

By elevating the testing team such that they have special privledges – i.e. that they don’t have to follow the rules – the group becomes politicised.  People who want the special prevlidges enter the group, the knowledge of testing becomes corrupted, and operational innovation is restricted as the group uses its power to focus on changing others and not themselves.

All of these ‘problems’ are not problems if you are in the group.  However, the testing group will be different group then had it not be politicised, the performance of the group may not be as it would have been, and the overall performance of the organisation that the group is a part of may also suffer.

This is melodramatic in many ways.  Because these things will only occur over time, and only if all others things are equal.  In reality other groups and specialisations will compete for power and the dance continues…

Des Moore on Central Banks

Interesting:

First, contrary to popular interpretations, the blame for the panic cannot primarily be placed on irresponsible bankers: they responded rationally to the subsidy for credit created by central bankers.

But what’s this in the very next paragraph?!?!:
Second, Prime Minister Kevin Rudd is clearly wrong in attributing the crisis to policies that reflect the neo-liberal views of free marketeers. Few if any supporters of free-market policies believe there should be no regulation of monetary conditions. (emphasis added)
Both from The Age.

Manager veto and the management team cartel

There is an interesting lesson about management intensions at the Management Skills Blog.   It serves as a good example of how management teams act like cartels (if you use my analysis approach):

 

Noble Intentions

Thu, May 14th, 2009 by Tom Foster

In 1948, in London, Elliott began to work closely with the Glacier Metals Company, a manufacturer of precision steel ball bearings. It was a company of some size and technical complication, with different departments, a complement of engineers, a management team and a president named Wilfred Brown.

Like most companies, each week or so, a high level meeting took place, called the Management Team Meeting. It was Wilfred’s intention to purposefully build his executive team by including them in on the company’s largest problems to be solved and decisions to be made.

The executive team responded with enthusiasm to be included in such important activities. By harnessing all the brain power in that room, certainly, they could tackle the toughest challenge and make the best decisions.

The intentions were noble.

As time went by, however, the productivity of the group began to wear thin. In their efforts to reach consensus, to be cooperative and supportive, to be the team they intended to be, the pace began to slow. Discussions became arguments, agendas became political, quid pro quo became active.

And then, the unthinkable. The group would finally arrive at its decision and Wilfred Brown, the President, would invoke his veto.

– from Management Skills Blog ‘Noble Intentions’

My comments are:

The problem is the concept of the ‘management team’ itself.

In my analysis a management team is a cartel!

Which means that when a management team come to agreement – meaning they come to agreement on the value of certain actions and decide the most appropriate action based on their combined assessment of the value of each alternative action – then they are in fact breaking the ‘price system’.

In a real cartel this means they agree on a price, bypassing the price system, and hurting consumers.

In the ‘management team’ cartel they are agreeing on the next action, bypassing the planning process, and hurting capabilities (and consumers).

I’m interested to see how this lesson plays out at Management Skills.

No wrong way to slice the pie? (and do you even know?)

Management, as a discipline, has a problem it can”t solve.  It needs to coordinate separate but related activities caused by the division of labour.  And it needs to be able to do this regardless of how labour is divided.

Project management, in particular, has this problem.   I’ve said before that project management is a perfectly reasonable discipline as long as it doesn’t try to cross organisational boundaries.  This is why project management is necessary but not sufficient in managing outsourcing.

Likewise, program management – which the discipline likes to define as the management of multiple related projects – isn’t really a separate discipline because of the scale of the work or the number of projects, it’s a separate discipline because multiple projects have multiple project managers.

Unfortunately, the accepted tenets of management simply do not scale.   Multiple managers causes more problems than they solve – and therefore situations which require multiple managers need other practices to govern them.

The root of this problem is that ultimately, the discipline of management doesn’t in itself offer any useful advice on how to divide labour.   It takes it as a given that labour is divided and then attempts to coordinate that.

Equally, managers – when you switch them on and give them responsibilities – tend to manage to those responsibilities.  Good so far, but if the division of responsibilities isn’t right there is a problem.  The problem might even get bigger if the managers are better.

But there are right and wrong ways to divide labour.  Some activities are autonomous and some aren’t.  Dividing management responsibilities and activities has its own additional challenges.

Only ‘architecture’ (which I define in this context as deliniated shared understanding) can offer any help in the actual division of labour.  However, architecture must be domain specific.   In order to determine correct/incorrect or efficient/inefficient divisions of labour it must take into account the domain and the required outcome.

(by the way, if you think a ‘strong management team’ solves this problem check out my article on ‘Management Teams as Cartels’)

Thought of the day

Mainstream economics is not the cause of the current financial crisis – rather, the cause of the current financial crisis and the cause of mainstream economics being mainstream are the same.

(article to follow)

Thought of the day

Leadership is knowing what needs to be done before you see the ROI calculation

Page 18 of 21

Powered by WordPress & Theme by Anders Norén