Author: mdegeorge Page 15 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.

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 –

Managing without general management at Apple

By mdegeorge

On May 10, 2011

In Uncategorized

Everybody is talking about the article on Apple in the May 23rd issue of Fortune.

Some interesting quotes that I might get around to commenting on one day:

And

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.

Healthy information eating

By mdegeorge

On January 11, 2011

In Austrian Economics, General Management, General MWT, Personal, Technology-Enabled Business Transformation (TEBT), Thought of the day

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.

Draft article: Building an Effective Business Architecture and Metrics Capability

By mdegeorge

On January 11, 2011

In Enterprise Architecture

This is a draft article entitled “Building an Effective Business Architecture and Metrics Capability”.

Chief Detail Officer

By mdegeorge

On December 13, 2010

In Uncategorized

Interesting talk on the often ignored category of low cost / high impact activities.

Business Architecture in the never-ending standardisation process of EA

By mdegeorge

On October 26, 2010

In Business Architecture, Collaboration Architectures, Enterprise Architecture, IT Management

At the risk of being controversial, I don’t believe enterprise architecture is about “alignment between IT and the business”. While there is not doubt that an effective enterprise architecture practice will improve this sort of alignment, it needs to do more than improve the standing of IT or the percentage of the value pie that IT gets credit for.

Enterprise architecture is a process. But it’s not a process of creating as-is architectures, creating to-be architectures, and then creating transition roadmaps. These are useful deliverables and will indeed be produced – but they are no more enterprise architecture than a MS-Project plan is project management.

The process of enterprise architecture is about identifying the activities, information, or assets that you want to standardise and then managing the level of standardisation actually achieved. It’s also important to note that this process occurs regardless of whether or not the process is called enterprise architecture.

If you look for it, this generic process of standardisation is everywhere. Even the idea that organisations have ‘products’ and ‘services’ is a form of this standardisation. It doesn’t require an enterprise architect to see how it would be beneficial to have some standard definition of what you do for your customers.

Another example is in the familiar department structures we see in most organisations: HR, finance, IT, etc. It has been determined in the past – and may well still be true – that it makes sense to standardise how, for example, payroll is processed. So you have a payroll department rather than all business units separately designing payroll processes. It also makes sense that you’d want to standardise the way products are matched with customers. Although increasingly separate strategies in the information age, this standardisation is traditionally achieved in this case by centralising these activities into a marketing department.

This standardisation in department groupings helps to align each organisation’s capabilities with the dynamics of the labor market. It also promotes efficiencies through specialisation and definition of labour. It may not always be the case, but this generic continuous process of standardisation has created these particular groupings because there is value in standardisation in these areas.

Information technology – in the general broad sense that includes processes and methods, but also in common usage as technical I.T. Information Technology – also plays a role in this standardisation process. To use the payroll department as an example again, it is not uncommon to implement the end-to-end payroll processes beyond what is performed by the payroll department into an ERP package such as those provided by SAP, Oracle, JD Edwards, etc. This is a process of standardisation.

The real value of enterprise architecture is recursive and somewhat tautological. Enterprise architecture is a standardisation of the process of standardisation. It is an attempt at defining how this on-going process of standardisation can be managed. It’s not perfect, but it’s all we have as a method of managing this process of standardisation with any formality or openness.

Enterprise architecture as an overall integrated framework helps to standardise by providing standard categorisations, definitions, and layers in which standardisation can be achieved. For example, Technical layers allow for standardisation of platforms, infrastructure, etc. Whereas Application layers provide opportunities to standardise integration approaches, services, types of common application functionality, etc. At the Information layer it is standardisation of the definitions of information items that are important so enterprise architecture frameworks assist with that.

In all cases above, the benefits of effective standardisation include reduced costs, increased agility, reduced risks, and an increased capacity for innovation. The special challenge of the Business architecture layer is twofold. Firstly, it provides context for the other layers. Particularly for information and application layer standardisation, it is the only way to understand ‘effective’ standardisation of those other layers. Secondly, the business architecture needs to identify the areas where investment [in standardisation] will deliver the greatest value.

When is comes to business architecture the standardisation process revolves around ‘capabilities’. Remember, organisations will keep on operating regardless of what the enterprise architecture team does. So capabilities may be existing areas where investments can be made, or potential areas based on analysis of the organisation’s customers, strategies, and other capabilities.

Not all capabilities are equal, and the types and degree of benefits that can be obtained through investment will different. However, if you don’t know what your capabilities are then you can’t make decisions about which to focus on and which to ignore. The next blog entry will focus on business capability mapping and how it forms the core of the enterprise architecture effort.

One-Way Risk and Robustness of IT Projects

By mdegeorge

On September 5, 2010

In IT Management

The Agile Manager has a great post on One-Way Risk and Robustness of IT Projects. It calls for “more robustness in risk management” within IT projects. However, it’s critical of risk management that is “limited to maintaining a ‘risks and issues’ log, so it’s never more than an adjunct to our plan”.

I like the implication that risk management should be conceptually equal to the project plan within the management framework. The reasoning appears to be that the project plan is necessary but not sufficient for the success of IT projects because of inherent uncertainty in these types of projects. In particularly there is reference to project plans being treated to as “point projections – as opposed to probabilistic projections – of what we will do, when we will be done and how much it will cost”.

I would never criticise the concept of schedule management but we shouldn’t see risk management as just an ‘adjunct to our plan’ but rather something that should be managed as robustly as the schedule elements that are embedded in the plan. Incidentally, project management says this in theory too – but the practice is sometimes lacking.

Of course, I would also include architecture at the same level of schedule and risk management and not place architecture management as just an ‘adjunct to our plan’.

(Via The Agile Manager.)

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.