Category: Multisourcing

Cloud-First Policies vs. The Real Impact of Cloud

What a slow process it is to watch jurisdictions implement “cloud first” policies.  State and federal governments are all doing it and in the end they all look pretty similar.  Some might say it’s a policy of considered common sense, or a policy not to exclude the obvious.  At least the process is getting done.  
Though as I was reading the latest commentary on the Coalition’s new “cloud first” policy it struct me that this drawn out response is hiding some of the real impacts that Cloud will have. Not just as an obvious technology choice, but as a real disruptor to business and government.  
Of course, this “cloud first” mandate is always qualified – but it’s the nature of these qualifications that is telling.  In the case of the latest policy, the qualifications are simply that the Cloud solution also needs to be fit for purpose, competitively priced, and met the Protective Security Policy Framework.  So it’s a mandate to use the best approach even if it’s cloud. You’d wonder why you need a mandate to use the best approach so I’m sure the policy doesn’t fundamentally change the existing risk aversion, lake of knowledge and vision, or whatever else was stoping Cloud adoption in the first place.
As we know, the problem with mandates is that they tend to reduce individual accountability.  So the very real data governance and privacy issues relating to Cloud are likely to lose some attention for a while; particularly when paired with the removing of the need for double ministerial sigh-off for storing data off-shore.  I personally don’t see the problem with requiring double-ministerial sign-off to do something.  The only problem might be if I were one of the ministers who signed off and then something went wrong… Oh, hang on, I get it.
Problem is, like everything else, decisions are not just made by getting the right sign-offs.  You actually need to make the right decisions.  So policy that does nothing but try to gate decisions or make somebody accountable isn’t as useful as policy that actually helps decision-making.  There must be better uses for policy development effort than the use of Cloud as a technology choice.  Say for example as a disruption.  
The impact of Cloud on ICT strategy is that application architectures will be made up of silo’ed by highly functional applications that support a particular business function or customer touchpoint very well.  
These applications will also have imbedded analytics which already cover the management and operational decision-making relevant to the area they support.  
Integration will be achieved only where there is a business case to do so.  Except the integration imperative will be so strong – as its absence reduces enterprise agility – that there won’t be individual business cases for each integration.  Instead, a top-down approach such as enterprise information management (EIM) will be used to build a single cohesive business case for integration as part of a program of driven by information governance, analytics, business intelligence, and the recognition of what I call “core shared information”.
The impact of Could on organisational design is that the functional organisation is dead.  The ability to acquire cloud-based services that provide not only the application services, but in the case of business functions the backend management of the function itself, means functional organisation is no longer viable.  
The management trend where everything of value is being managed as “a cross-functional team” is now the norm.  The only thing left is to remove the functional organisation that created that language in the first place.  Functional organisation made it easier for managers (i.e. to shift across organisations, and also because they only had to understand how their function fits + strong stakeholder management) now managers have to be better at managing.  Though they also have better [cloud-enabled] management tools to help deal with this.  
Impact of cloud on information governance is that it’s time to disconnect Cloud from information governance and privacy issues.  Dumping the off-shore data double-ministieral sign-off policy because it happened to be inconvenient to Cloud initiatives is simple baby-with-the-bath-water stuff.  
Sending personal data off-shore is still a breech of Australian privacy legislation if this hasn’t been agreed with the individuals who own that private data.  Organisations are still at risk of legal action if damages occur due to mis-handing of personal data.  So this shouldn’t have ever been mixed up with Cloud.  
Impact of cloud on business strategy means that your differentiation cannot be based on what is easy to acquire – because value comes from scarcity not from abundance.  Actually this has always been the case but the impact of Cloud is the breadth and depth of things that are now easy to acquire.  
Your ERP was never going to differentiate you from your competitors.  But because it was expensive it was able to provide a competitive advantage at a pinch (as long as the business case held up after the inevitable cost overruns).  Now that ERPs and significantly more valuable targeted services are available in the cloud they are much easier to aquire.  So they have value, sure – but don’t have value as a differentiating feature of your organisation.
The impact of Cloud on government is that there are so many things that peer-to-peer markets can do better than government.  The government shouldn’t just be shifting the services they offer to cloud-based solutions. The government’s Cloud policy should be how does a cloud-enabled market solution remove the need for this government function?  How do we ensure services are more effectively targeted by using Cloud services to manage the market for services?
In a way, the impact of Cloud is nothing more than the impact of lower transaction costs played out on the acquisition of services.  Sure, it’s probably bigger than that be it will be called something else by the time it become outcome-as-a-service.  So for now “Cloud polices” are the place to ask the disruptive questions.  

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.

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’)

Multisourcing disipline: ‘New’ to MWT

There is no avoiding it.  There is an overlap between some aspects of the MWT Model and what is increasingly called Multisourcing. 

The Multisourcing dicipline really is beyond procurement, outsourcing, and supplier management.  Multisourcing is both a strategy and a strategic capability of the client organisation.  It is the end-to-end process of service definition and management, selection of who will perform services, decisions on where services will be performed, and the related governance and performance management.  

Though in truth, the diciplines relating to Multisourcing can be relivant even to organisations which deliver services using predominately on-shore, in-house capabilities.   This is where it relates most interestingly with the MWT Model and service-based management in general.  

I have created a new blog category for posts relating to Multisourcing.  This is such an important disicpline I would expect these would be of interest to anybody with an interest in the MWT Model.

If you’re already keen to learn I recommend Multisourcing: Moving Beyond Outsourcing to Achieve Growth And Agility.

Powered by WordPress & Theme by Anders Norén