Category: General MWT Page 1 of 4

Trying to Implement the Functional Organisation

In that perverse type of functional organisation that has a functional business unit for each profession, there is a predictable progression for each function.

  1. The function cannot succeed until it is centralised
  2. The function cannot succeed until it has the sponsorship of the CEO
  3. The function cannot succeed until it has its own “Chief xxxx Officer”
  4. The function cannot succeed until everybody understands that the function is “everybody’s responsibility”
  5. The function cannot succeed until it has the resources to engage with “everybody”
  6. The function cannot succeed until there is a dedicated business unit that makes the function part of the business-as-usual process
  7. The function cannot succeed until it has input into the strategy of the organisation
  8. The function cannot succeed until it is part of the organisation’s culture
  9. The function cannot succeed until it reports to me

 

The No ICT Strategy Organisation

The idea of business / IT alignment is completely at odds with the challenge of business agility.  You can never align all-of-the-business with all-of-the-IT.  You can only ensure that the business capabilities your organisation’s operating model depends on sufficiently utilise information technology in order to ensure competitive levels of productivity, optimal customer experience, and coordination with other business capabilities.  
 
The idea of business / IT alignment is admirable when it implies that in model business operations there is a concept of “business” concerns and their is a concept of “IT” concerns and that they are peers.  The process of business / IT alignment then would be a messy and complex process that might eventually work.  However, business / IT alignment never gets implemented as a process that assumes business and IT are peers.  Even if it was, it’s foolish to break your organisation along the lines of business versus IT – there are other ways of cutting up the organisation that eliminate the need for business / IT alignment altogether.  
 
This is further exacerbated by the shift of IT budget to business units.  Once budget that had traditionally been thought of as IT budget gets shifted into, say, marketing, it would be ridiculous for the marketing department to then raise a concern about the business / IT alignment challenges they were having when spending their new increased budget.  Once you’re responsible for both why complain about alignment?  If you own the budget you have nobody to complain about business/IT alignment to.
 
I’ve written before about how much of what people in the so-called “business” think of as “IT issues” are really related to information, complexity, or simply willingness to spend time on the details.  When a business process is automated – does it then become an IT problem?  It is a sign that our understanding of the dynamics involved in the implementation of information systems – which it is now trendy to call “digitisation” – has certainly outpaced our popular understanding of how organisations are designed and governed when these simple questions still have complex answers.
 
We have a number of real problems governing our organisations.  Business and IT concerns aren’t ever broken down to specifics, the whole concept of splitting business and IT places barriers to true organisational agility, and there still isn’t an understanding that in the modern world the high-level concept of “the business” and “IT” don’t exist.  This separation is make for the convenience of executive leadership and have limited organisational value.  
 
I’ve previously proposed the simplest change might be to stop creating ICT strategies.  I’m not saying an overall strategy for certain aspects of IT isn’t required.  I’m simply saying that an overall strategy for the organisation is more important.  If you have a business strategy and an ICT strategy is it any wonder you have business / IT alignment issues?  Of course you have alignment issues!  You have two seperate strategies. 
 
This is exacerbated by the fact that your business / corporate strategy  probably doesn’t contain the sorts of things the folks developing your ICT strategy expect to see anyway.  They probably have to go to individual business unit strategies to get the information they need and ultimately the ICT  folks are left to try and align the inconsistencies that will inevitably exist between all of these business unit strategies.  
 
A strategy development and strategy deployment process grounded in business capabilities is of course the answer.  

Blast from the past: “Organisational Usability”

I’ve had to delve into the Internet Archive Wayback Machine – to about 2005/6 it looks like to find an old article I wrote on “Organisational Usability”.  I thought this was going to be big at the time.  In fact I think it is starting to be big:

See here for original article: http://web.archive.org/web/20060507201901/http://www.managewithoutthem.com/show_article.asp?statement_id=114 

…and the MWT Archive here: http://www.managewithoutthem.com/Archive-Feb-2007/MWT%20Complete%20Archive%20Feb%202007.pdf

 

Organisational Usability I

 
Related Articles

The Internet:
Anti-Capitalism or Hyper-Capitalism?

MWT Systems Framework
Managing At, Managing Within, Managing Out…!

   

In the hyper-capitalism of the Internet your web site’s usability can make or break it. A bunch of competitor web sites are only a click away; so if your site is too hard to use, ‘click away’ your visitors will. If the effectiveness of your web site depends on its usability, why not use that model for your entire company? 

One of the Core Concepts of ManageWithoutThem is Organisational Usability. Organisational Usability is a broad term, created specifically for the ManageWithoutThem model. We will be revisiting Organisational Usability in future articles.

Organisational Usability uses the analogy of an Internet web site for your entire organisation. It is the advent of the Internet (and other personal communication technologies) that has made apparent the need for organisational redesign – so the analogy is a good fit.

Your organisation exists as a resource to be used by your customers and your employees. That is not to say that your organisation should be left to the whim of your employees and customers. What we mean is that as your employees are serving customers or creating new value through projects, they are leveraging the resources of your company. In this sense, your customers and employees are ‘using’ your organisation.

The effectiveness and efficiency in which the resources of the organisation can be leveraged is the Organisational Usability of the organisation.

And now some examples of the Web Site analogy in action… 

Link to Homepage

One of the first lessons you learn in any web site usability course is that each page should have a link to the home page. This is because users of your web site might not enter the site from your homepage. Users need a way of exploring other pages of your site and other information or services you might offer.

As you gain experience with web site development you start to realise that the ‘link to homepage’ approach is an inadequate solution to the problem of mid-site entry into a web site. In Organisational Usability this is the equivalent of having to call the CEO to get something done!

Links to Related Services

Your organisational will have high Organisational Usability if it has a more sophisticated strategy than ‘ask the CEO’ whenever somebody finds itself lost within it.

Departments, particularly shared service providers, should be aware of any services that are related to their offerings. This will include relationships up and down the value chain, as well as peer relationships. This will also include relationships outside your company. Your IT department should know about the IT industry. Your Accounting department should know about the Accounting industry. Your Procurement department should know about the Procurement industry. (etc)

Pre-emptive Processes

When somebody visits your web site you have no idea how much of their purchase they have already completed. The web site user might need background information on how to start looking for products in your industry. Alternatively, the web site user might already have a part number and their credit card ready.

The importance of this to Organisational Usability is that the customers and employees of your organisation may wish to enter your processes from a point other than the beginning.

Equally as important, your employees and customers will be of varying levels of sophistication. Some may want you to manage things for them; but others (probably the best ones) will want to manage things themselves.

Still more sophisticated, might be those that want to ‘outsource’ the activity you provide for them – with very high expectations of service and quality. It is also likely that users have entered your site through a Portal of some kind.

For these reasons your customers (or employees from other departments) may not always want your Project Management services. Your customers may want to define their relationship with your process themselves.

Process in context

Your web site might have the most easy-to-use ordering system ever created, but it is not very helpful if your customers can’t get to it from the product they wish to buy. For this reason, the practice of placing ‘Buy Me’ and ‘Go to Checkout’ buttons beside each item is well established.

As far as Organisational Usability is concerned it should be understood that the context of day-to-day business will never be your companies business management system (which lists all of your organisation’s processes) – and you don’t want it to be.

If you want employees and customers to use particular processes you should think very carefully aboutwhen they will need to use those processes. Process owners should ask themselves: What would an employee be doing at the time that they should use my process? Then, every effort should be made to make the process visible from that context.

Frames

For those that don’t know, ‘frames’ (or ‘framesets’) is the term used when building web sites to describe a page made up of multiple sub pages viewed together. Frames are often seen as poor web site design because you don’t know if you are viewing a page as a stand-along page or if you are viewing the page in the context of the rest of the frameset.

In terms of Organisational Usability frames represent the other things that your employee or customer knows when they use your processes. The fact is they may know more or less than you expect.

Markets: Employees and Customers Converge

There is constant reference to Employees and Customers within this article. The traditional view of organisations requires you to view these as fundamentally different groups. Once you start viewing your organisation from the perspective of it’s Organisational Usability your will see these two groups converge.

After all if your company’s web site really does provide useful information about your organisation your employees will also visit it regularly.

 

It’s not all about people – it’s about respecting people enough to make the systems work

How many times have you had an employee come to you with a complaint about how a process works, or how an IT system is broken, or how they aren’t getting along with another department, and you’ve basically counselled them. You’ve told them how they might get a better result if they approach the situation a different way. Maybe you’ve suggested that they escalate this to another person. Perhaps you’ve even brokered a meeting where the two groups just sit together to rebuild their relationship – just try and see it from each other’s point of view.

You take this approach because people management is important, right? You take this approach because “it’s all about people”. But don’t you think if the system wasn’t broken there would be less of these “people issues”? It’s the most respectful thing you can do for the people in your organisation to make the organisation itself work better?

That fact of the matter is that your people are not your most important asset. Your systems are your most important asset. Because when your systems work, and make it easy for your people to operate your organisation (i.e. what I call “organisational usability”) then your people will stay. Your “assets” support your customers first, and your people second. And that is all. To say your people are “assets” is actually pretty offensive.

The fast is you need good people if you want to change anything. People have ideas, people make stuff happen. But the more you are relying on people to do basic tasks, work arounds, and counselling sessions, the more you are destroying the competitiveness of your business by adding unnecessary costs to the cost structure.

The idea that you should focus on making your organisation a “great place to work” doesn’t contradict this in the slightest. Being a great place to work means the people in your organisation aren’t constantly trying to avoid being the ones who do the low value jobs. Being a “great place to work” means that management systems are in place that ensure that you don’t have to suck up to your line manager in order to be recognised for your contribution.

Constantly focusing on the people, at the exclusion of focusing on the systems, is completely counter-productive. Of course, I mean “systems” broadly, beyond IT systems. But more importantly, I mean the systems that create a set of unique capabilities controlled by your organisation and connect those capabilities to customers.

The only reason managers focus on people is that they want to manage them – read: control them. If you make everything into a people issue you don’t have to fix your partner eco-system, you don’t need to have a strategy, and you don’t need to manage risk. Or more importantly, you can focus on your own career progression rather than making the systems work for people who operate them (too cynical, perhaps?).

By focusing only on people you just get to wake up in the morning, see what’s failed and fire somebody, or ask everybody how they are adding value and let them take the effort to justify. This is the extreme but natural conclusion of how focusing on people plays out. By only focusing on people you’ll find yourself saying things like “Bob doesn’t get it” when there is no “it” to get. Like I’ve said before “management at it’s worst is the art of saying ‘you’re not seeing the big picture – even when there clearly isn’t one'”.

The more you focus on the people, and the less you focus on the systems, the more you’ll need to focus on the people. People in an untidy, unstructured, and ultimately political environment will undoubtably require more attention. People who need to end their day manually collating information and re-typing into systems that don’t work will require more attention. People who need to collaborate across teams where no agreed protocols exist will require more conflict management. People who need to suddenly “do more with less” will – by definition – actually do less with less until the systems change.

It’s time to respect people by managing systems.

 

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

12 years later

Twelve years is a long time.  But I found this on my laptop last night – although it’s 12 years old it’s still a pretty good representation of how I think about what I do.

Philo

Management as a service, again

Nice:

If everything is a service, why should management be assigned any priority over anything else?

Short answer: no valid reason at all – from a services-perspective, anyway. It’s just another service, or set of services.

The only feasible reason why management might be assigned arbitrary priority over other services is from left-over delusions about ‘rights of control’. For the most part, these delusions arise from an unfortunate coincidence of functions within the ‘management-services’:

services for strategic-assessment – potentially giving the delusion that ‘knowing more about big-picture’ inherently means ‘responsibility to tell others what to do’
services for coordination of resource-allocation – potentially giving the delusion of authority over others via ‘right to withhold’, in turn arising from delusions about the (dys)functional role of purported ‘rights of possession’ within the broader society, and hence within an organisation’s economic model.
In short, architecturally speaking, this is not a defensible reason for priority. Every service is ‘just another service’ that is required for enterprise viability: hence no service can be said to have inherent priority over any other.

read it all here:
http://weblog.tetradian.com/2011/09/26/rethinking-architecture-of-mgmt/

McKinsey notices that management models can be impacted by technology!

McKinsey, ten years after I started saying that we should be focusing on using technology to change how we manage rather than over complicating how we manage technology, is now saying companies that integrate Web 2.0 technologies into their work flows perform better:

http://www.mckinseyquarterly.com/Organization/Strategic_Organization/The_rise_of_the_networked_enterprise_Web_20_finds_its_payday_2716

Shame people have to wait until the data is available before they believe this 🙂

Some extracts from the Collaboration Architecture sections of the MWT book which talk able Collaboration Architectures – which is what we are really talking about (not Web 2.0):

– link coming soon –

Architecture Versus Management?

I’m increasingly seeing the management and architecture disciplines as being in a race to control organisations.  Both groups show behaviours that suggest they are trying to extend their own discipline to encompass more of the organisation.  Equally, both groups work hard to exclude areas they are not comfortable with from their responsibilities.  Architects want to control the organisation by controlling knowledge of the structure and value streams at all levels, while avoiding execution issues.  The management profession wants to control the organisation by controlling resources, while avoiding responsibility for technical issues.

Both the architecture and the management professions reveal their desires to control the organisation by the manner in which they grow the scope of their approach through ever increasing extensions of their disciplines.  The management discipline has grown from supervision, to general management, to strategic management, to change management, and to all of the business unit focused sub-disciplines that form the structure of a management degree (finance, HR, etc).  Conversely, architecture has grown from a technical discipline to include information architecture, solution architecture, business architecture, and information architecture.

Christopher Alexander popularised – if his ideas can be considered popular – the idea of generative sequences.  In essence, a generative sequence is the process of taking a structure and changing it through a series of structure preserving transformations. After each transformation the whole structure is then evaluated to determine if the transformation has – more or less subjectively – improved the structure.  This process is repeated.  Alexander also defines the so-called structure preserving transformations that are applicable at each step.

This is an interesting analogy to decision making in organisations.  Each time a decision is made the structure of the organisation changes.  Structure in this case may refer to anything: including the attitude of an individual team-member, the next task to focus on, or even quite literally a change in the organisation’s structure as we usually use that term.

What is interesting is that from both the manager’s point of view and the architect’s point of view the details of that structural transformation are only selectively considered.  Because managers are generally outcome focused, each transformation or decision is evaluated based on its perceived contribution to outcomes.  These outcomes may be long or short-term, or they might be project-focused, or they might relate to the entire organisation – but it’s the outcome that’s important.

While management is primarily concerned with outcomes, the architect is concerned with structure as a whole.  When decisions are made they not only impact the progress towards goals but they may also potentially impact other structural elements of the organisation.  Rather than a distinction between long or short-term time horizons, or between technical and business domains, the distinction between architecting and managing is generally about outcomes versus structure.

Currently, it’s difficult for architects to evaluate the impact of a transformation in terms of the progress towards desired outcomes because a comprehensive view of the desired outcomes is rarely shared, documented, or linked to the structural elements as defined by the architect.  Similarly, it is difficult for a manager to utilise the models created by the architect to make decisions because the models which describe the structure use technical language and contain much that is irrelevant to decision making.

This battle is not yet won, of course.  To be a successful architect you must manage carefully, and to be a successful manager you most certainly need to be an architect of sorts.  The MWT Model is driven from the theory that this battle will and is ultimately changing the practice of management itself.  This may be seen as victory going to the architects but is more likely to mean that successful architects will no longer be able to choose what issues they avoid.

While this might be interesting to professionals on both sides of the battle I’m just as interested in how important this is to the organisations that we work in.  As I’ve said before, I believe good IT is structural – when you implement an HR system that enables you to re-deploy some employees in the HR branch of the org chart, you should really hang that HR capability embedded in the IT system in their place.

As these structural IT changes are increasingly differentiating organisations and brokering their relationships with customers it is ever more important that organisations can effectively operate and enhance these technology-enabled capabilities.  Both managers and architects currently struggle to achieve this and in the organisation of the future (now?) it’s really the only game.

 

Healthy information eating

I’m looking forward to a few weeks off before I begin a new role in a technology & management consulting company (which I’m also very much looking forward to).

I’m planning on going on an ‘information diet’ during my break and have already cleared inboxes, unchecked starred items, and unsubscribed from plenty of RSS feeds.

But what sort of a diet would it be if I didn’t ensure I got enough nutrition?  So I’ve also enrolled in a course at the Mises Academy.  I’ve chosen “Networks and the Digital Revolution: Economic Myths and Realities” because I’ve always liked reading snippets of Peter Klein.

One of the features of the Mises Academy (other than that the courses are cheap and on line) is that the readings are generally available for free.  While working through the readings for my course I came across:

… They hit gold with ”The Nature of the Firm,” a 1937 paper written by the Nobel laureate Ronald Coase.

The Coase paper asked a deceptively simple question: If the market is such a great tool for allocating resources, why isn’t it used inside the firm or company? Why doesn’t one worker on the assembly line negotiate with the worker next to him about the price at which he will supply the partly assembled product?

That sort of negotiation rarely happens. Instead of using markets, companies tend to be organized as hierarchies, using a chain of command and control rather than negotiation, markets and explicit contracts. Paradoxically, the primary unit of capitalism, on close inspection, looks a lot like central planning.

Mr. Coase didn’t just ask this question; he also provided a provocative answer: it all hinges on the costs of making transactions. What economists call firms, he said, are essentially groups of activities for which it is more effective and less costly to use command-and-control than markets to have things done.

New-economy advocates found this a compelling idea. One consequence of the Internet has surely been to make it cheaper to communicate. This should, in turn, lower transaction costs and change company boundaries. Their conclusion was that companies would inevitably downsize and outsource, spin off unnecessary functions, and carry out more and more transactions using the Internet instead of internal memos.

Not so fast. The Internet lowers communication costs, that’s for sure. But that means it lowers transaction costs within organizations as well as across organizations. The internal memo might disappear, but only because it is replaced by the internal e-mail message.

It just doesn’t follow that lower communication costs lead to smaller companies. In fact, Mr. Coase himself said that ”changes like the telephone and telegraphy, which tend to reduce the cost of organizing spatially, will tend to increase the size of the firm.””

– from here with my emphasis added

I’ve read some of the original Coase papers over the years and the idea of reduced transaction costs have been at the heart of the MWT Model.  I like this idea that a key capability required in a low transaction cost world is likely to be the ability to work effectively with, and generate value from, low transaction costs within organisations and also across organisations.  To me this is the whole point of how management is changing / needs to change.

I also like that this is still an interesting idea to me.  It’s a calling of sorts and something I tend to think about even when I don’t have to. It gives me energy and purpose.

 

Page 1 of 4

Powered by WordPress & Theme by Anders Norén