ManageWithoutThem

Blast from the past: “Organisational Usability”

On November 26, 2012

In General MWT, Innovation, MWT Components, MWT Themes, Thought of the day

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.

12 years later

By mdegeorge

On March 15, 2012

In General MWT, MWT Themes, Personal, Thought of the day

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

Thought of the day: Information management is management

By mdegeorge

On October 16, 2011

In MWT Themes, Thought of the day

This thought has kept occurring over the last few years:

“Information management is management”

This is true in a number of ways:

traditional styles of management maintain their power by withholding information
market-based management increases transparency through information
there is now to much information – and managing it sometimes feels like the whole deal
market-based management ensures integration of feedback – usually in the form of information
market-based management ensures the manipulation of the right information has appropriate impact on the performance of the organisation (i.e. manage the information and you manage the organisation)
The Hayek “The Use of Knowledge in Society” sense

Management as a service, again

By mdegeorge

On September 26, 2011

In Business Architecture, Collaboration Architectures, Enterprise Architecture, General Management, General MWT, MWT Themes

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/

Architecture Versus Management?

By mdegeorge

On March 1, 2011

In Business Architecture, Christoper Alexander, Enterprise Architecture, General Management, General MWT, Pendulum Argument Augmentation, Technology-Enabled Business Transformation (TEBT), Thought of the day

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.

Note to self: do ERP vendors benefit from the sunk cost fallacy and asset specificity?

By mdegeorge

On September 1, 2010

In Accounting Failures, Ideal Realised Strategy, IT Management, IT Vendors failures, Personal, Thought of the day

I’ve never really been very interested in ERPs – so I likely don’t know what I’m talking about…

But over the years there have been many times I’ve heard organisations saying they need to “leverage their investment” in their ERP. This is usually after they have spent far too much money implementing it in the first place so whenever I hear that phrase I can’t help but hear “we don’t have the expected benefits from this yet so we should invest more in it because we’ve already invested too much not to get any benefits from it”. This is clearly the sunk cost fallacy at work.

There has been talk of the end of ERPs for some time, and there are certainly many web-based alternatives, much-hyped redesigns, as well as web based versions of classic ERPs. But at the same time ERPs aren’t going away. Certainly the companies themselves are far too clever to not evolve.

But I’m more interested in why the benefits aren’t realised. Because from an enterprise architecture perspective there are certain elements of the ERP value proposition that make perfect sense. If you think of enterprise architecture as primarily being about finding the capabilities, services, and processes that you want to further integrate or standardise across your organisation (and I haven’t found a better definition) then taking disparate payroll, HR, procurement (etc, etc) processes and standardising them should delivery value.

I’m going to make a leap here and say that ERPs actually do deliver value. In fact, any critic that suggests otherwise probably has a skewed view of why we use information technology in our organisations in general. The problem with ERPs isn’t that they don’t deliver value – it’s that they are incredibly overpriced.

Given that organisations pay that price I have to wonder how ERP vendors are able to extract value from organisations so successfully. Going back to my limited experience with ERP implementations I see three ways ERP vendors extract value from organisations:

1) ERP people are over specialised. While development and support for software packages from mid-sized vendors, or custom software development can be implemented with a variety of method, tools, and resources, a SAP implementation for example must be staffed with ‘SAP people’. There are no business analysts, developers, or project managers. There are instead SAP Project Managers, SAP Developments, SAP Business Analysts. This of course creates a scarcity of quality resources and the subsequent high price of those resources.

2) ERP vendors force their customers to follow an Ideal Realised Strategy which says your implementation will be simple if you don’t customise your implementation. However, by virtue of the fact the everybody customises their implementation this doesn’t seem like a feasible strategy in practice.

3) ERP implementation partners take control of both IT change and business change. However, rather than take the approach that business change is about delivering benefits and increased productivity they appear to take the approach that ‘business change’ is all about making sweeping changes to work practices rather than making small changes to the product. i.e. by owning business change they are using it to the vendor’s advantage not the client’s advantage.

Long-overdue rant complete.

Ideal Realised Strategies and Enterprise Architecture

By mdegeorge

On August 29, 2010

In Enterprise Architecture, General MWT, Ideal Realised Strategy, Pendulum Argument Augmentation

There are two important themes in the MWT Model that are used to shift organisational habits. These are ‘pendulum arguments & something else’ and ‘ideal realised strategies’. Pendulum arguments are issues like the ‘centralise or decentralise’ debate that cause organisations to continuously cycle through organisational design or financial control models. These pendulums must be fixed with ‘something else’ – such as an operating model or a collaboration architecture in this case.

Ideal Realised Strategies are a separate category. These are the problems when a strategy is proposed or in place that only delivers an acceptable balance of benefits and risk if it is implemented perfectly (which of course number happens). In the context of the MWT Model, these are usually management strategies such as ‘ensure you confirm that you have closed all issues by the milestone date’.

Ideal Realised Strategies often have unstated dependancies or are otherwise unfeasible. Ideal Realised Strategies also tend to keep people in positions of power because they need to be continuously funded and supported while the strategy endlessly edges towards perfect implementation.

As I spend some time thinking about enterprise architecture I’m starting to see the whole practice of enterprise architecture as an Ideal Realised Strategy. I was also struck by title of this article (“What to enterprise architecture and socialism have in common”) and as a Mises-head of sorts didn’t like the comparison.

I usually place enterprise architecture (EA) as the anti-thisis of the overtly political approach to organisational design and decision making inherent in the managerial approach. But not everybody places EA in this context, and it sometimes appears that as EA ‘matures’ to prescribe governance and business architecture approaches it is increasingly making its success dependant on more total control of the organisation.

Any strategy that has its success based on increasingly total control of the organisation that it supports is by definition an Ideal Realised Strategy.

Once I see EA this way I can’t help but think that it’s also evolving into a form of technocracy in the same way I have argued that managerialism is technocratic. It also risks becoming part of a pendulum argument in the way I have seen organisations swing from sales lead (“if we don’t sell anything it doesn’t matter what we deliver”) to delivery lead (“if our delivery suffers our clients won’t want to buy our product no matter how good our sales people are”).

EA is changing – needs to change – but let’s get this right.

Update: there are some nice hints towards an EA approach less obsessed with centralised power in the Gartner press release I’ve previously referenced.