I just found a nice overview diagram (nice in content, not in style) where I thought I’d solved the problem of creating a customer-centric organisation just by breaking the challenge into its components.
It’s a year or so old but to be honest it still looks about right:
PDF: The Problem of Customer Orientation is Largely Solved – if you have the will to implement
It’s often difficult to understand how your portfolio of projects is actually helping your organisation deliver to its strategic goals. The problem is that the projects in the portfolio often don’t play a part in ensuring the overall portfolio is easy to navigate and cohesive. You need linchpin projects in your portfolio to hold the others together.
Linchpin projects are different to other projects in the portfolio. Linchpin projects don’t have a business case in the traditional sense – because they are strategically placed into the portfolio to hold it together, identify risks across the portfolio, and steer cross-project decision-making.
Linchpin projects are value-seeking initiatives that raise the value of the entire portfolio. In fact, linchpin projects represent the new normal for combining operations and program management in the digital economy.
Your current portfolio
Your current project portfolio is probably made up of three types of projects:
The decisions that initiated each of these projects aren’t always perfect. But you have no choice but to plunge ahead with the projects. However, each of these types of projects presents challenges to the management of your portfolio as a whole:
Major projects versus linchpin projects
It’s a mistake to think of your major projects, or your strategic projects, as your linchpin projects. Major projects are often run as exceptions, so the transformational impact of these projects is often limited or followed by organisational fatigue or regression. Linchpin projects on the other hand inject specialised disciplines into the portfolio and in many cases don’t need to be large investments.
However, there is an opportunity for your major strategic programs to host a number of linchpin projects to get them started. The trick is knowing which linchpin projects you need…
Which linchpin projects do you need?
Regardless of your organisation, the following linchpin projects should be in your portfolio. The characteristics of your organisation and current strategic direction will only impact the size and approach for each of these initiatives.
Project 1. Business capability based governance
Our organisations shouldn’t have a primary governance model that divides the organisation into functions and then constantly proliferates the need for cross-functional teams. Social enterprises don’t require this approach – so your organisation’s primary governance should be mapped to business capabilities, not functions. This is also the first step in ensuring “business/IT alignment” – by stripping back the historic and arbitrary separation that is the root cause of misalignment.
Project 2. Customer journey design & customer experience campaigns
If you can’t point to artefacts which describe an idealised view of how your customers experience your organisation, then you haven’t done enough thinking about your customers – and you have nothing to orient your organisation towards customer outcomes. Equally, if you can’t point to specific customer-facing processes, technologies, and metrics that continuously direct the resources of your organisation towards reenforcing positive customer experience and recovering bad customer experience – then your customer journey design is just sitting on a shelf!
Project 3. Asset life-cycle, utilisation, yield, and pricing
Airlines, hotel chains, mining companies, and farmers understand yield. They understand that large expensive assets must be effectively carved up to service the right customers, at the right time, and for the right price. In the digital economy this same process must be applied to every organisation’s assets. If you don’t understand the utilisation on your major assets, and how projects can impact this, then you are running a business that provides a higher cost product – or your are running a unsustainable business.
Project 4. Core shared data strategy, information asset governance, and decommissioning
Unmanaged, the information in your organisation can get out of control. We have access to so much technology – information technology – that is supposed to help us manage information. So why are there so many copies of the same documents? Why can’t we rely on information we receive from other departments? And what is cut-and-paste if not investment in the problem instead of the solution? The solution is to systematically discover and invest in information assets across their end-to-end lifecycle – focusing in particular on the “core shared data” that is key to coordination across business units. Oh, and don’t forget you can’t ever throw data away unless you know what it’s worth (i.e. Business value) – but some data you can’t afford to keep (i.e. Privacy Act).
Project 5. Combined process, information, and user forums – fit-for-purpose scorecards
Your employees know what is wrong. But there are few mechanisms for feeding that learning into operational improvement initiatives. Lean and Six Sigma ™ come to mind – but that’s just details. Whenever your process team talks to people who should be following processes – capture the reasons why they’re not! Whenever you find yourself questioning a decision an employee has made – capture the missing information that caused the wrong decision to be made! Whenever somebody throws their keyboard across the room – ask them why! Better still – combine all of this into a single session which uncovers what is wrong around this place.
Project 6. Innovation funnel, lean business case, and start-up support
Innovation, or rather an entrepreneurial culture, starts with hiring entrepreneurs. But what if you can’t keep them? There are three reasons you can’t keep them: 1. You don’t recognise the good ones – because you don’t have an innovation funnel. 2. You frustrate them – because there are too many barriers to implementing business cases for change. 3. They can get better, cheaper start-up support in the market. These things are easy to fix and can be funded to the extent that you value innovation.
Project 7. Voice-of-the-customer operational alignment – Customer Return on Operations
It’s pretty easy to gather basic voice-of-the-customer data. For example, you can just asked the simple “How likely are you to recommend us to your friends? And why?” questions at the heart of Net Promotor Score (NPS). The hard part is doing something about it. You need to systematically determine what parts of your operations have the most impact on your customers. Management of “customer return on assets” will tell you most of what you need to know about how your projects are impacting your performance – from your customer’s perspective.
Project 8. Competency centres and change levers – The Machinery of Business Transformation
There are two ways to transform your organisation: you could run a heavy transformation program, and then an even heavier organisational change management initiative – and hope you get both right. Alternatively, you can manage to a transformation agenda – vision – and a portfolio of integrated competency centres – collaboration and continuous improvement towards that vision. If you know your own organisation’s portfolio of competency centres, their service catalogs, their customers, and the most effective channels and levers of change for your particular organisation, then implementing your whole project portfolio, and avoiding unintended consequences, becomes much easier.
Project 9. IT federation: shrinking corporate IT and embracing shadow IT
Even with your primary governance now focused on business capabilities (see Project 1) you still need to manage IT. But the difference is you need to manage all IT, in the only way you can in a post-Cloud, outsourced, and BYO world – federated IT. Learn to manage IT without ignoring what is out of your control and you’ll revolutionise productivity within your organisation while spending less than you did on IT services, architecture compliance, and generally inconveniencing your stakeholders by trying to be the cost and standardisation tzar.
Project 10. Who are we: purpose, culture, communications, and performance
Engage, decide, communicate. There is always another opportunity to reinforce what makes your organisation unique. There are ways of doing this that improve performance. Try them.
A familiar anti-pattern to anybody who knows anything about security is “security by obscurity”. The idea of security by obscurity is that you can rely on withholding details of how a security protocol operates to increase the security of the protocol.
The simplest example might be if you store passwords “encrypted” but you don’t tell anybody that you are only decrementing each letter by one – so if your password is “IBM” it becomes “HAL” when “encrypted”. This isn’t a true, nor secure encryption; and keeping the details of the encryption secret don’t make it more secure.
This brings me to the “bring your own device” (BYOD) trend. This is basically the idea that employees, rather than using company issued work stations, could simply bring their own computing device and access corporate systems from that.
Too many people are focusing on the risks of BYOD rather than the opportunities. Do we have to code for multiple devices? What about security on their device? What happens when they resign? What right does the company have to the personal property?
But the reality is this is just like security by obscurity. We have been living in a world deluded into thinking that things would be simpler, and more efficient, if we all conformed. If only everybody had the same desktop environment, and we didn’t let anybody change anything without calling (and being told “no”) by the IT help desk.
We were living with the illusion of what I call “simplicity by conformity”. We choose an arbitrary object – our work stations – and decided everything would be better if they were all the same. But this simplification never happened. People had to find work-arounds to the rules that tried to create this conformity. And they weren’t finding work arounds for the fun of it. They were finding work arounds in order to try and simplify areas that actually mattered: servicing customers, working efficiently, collaborating with their teams.
So I see BYOD as the end of “simplicity by conformity”. By taking control of the device out of the equation we are forced to create rules that simplify things that actually matter. Real simplicity.
One last point – people working on their own device expect it to operate like their own device. If the attention economy has taught us anything it’s that we’ll shift our attention to things that are more entertaining – or those that have greater usability. Imagine how difficult it is to keep yourself from distractions as you work on your computer at work – and then magnify that by each distraction you’ll find on your own device.
The challenge of distraction is another hidden false assurance. We can no longer pretend that boring, meaningless work will be done efficiently because there is nothing else to do. BYOD will reignite the need to create engaging work. Conformity by engagement, perhaps? Perhaps not. But engagement around things that actually mater.
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.
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.
Whenever I read about enterprise architecture I’m always struck by how technical the conversation seems. I’m not anti-technical; but in my mind architecture is more important than what we generally call management. This is also implicit in the principles of the MWT Model. It is in fact architecture which I see as the centrally coordinating mechanism of organisations rather than management.
This means that at the specific level at which you are coordinating the architecture needs to be understood by all participants – not just technical people. If the level of coordination is the executive team making IT investment decisions the particular architecture is the enterprise architecture.
Now I’m the first to complain when IT Management becomes a race to the bottom and when IT Managers wear the statement ‘I’m not a technical person’ as a badge of pride (isn’t management ‘technical’?) but I’m talking about something different and specific here. If enterprise architecture has an intended audience that includes so-called non-technical people it cannot be technical.
The problem is, I find that enterprise architecture is always defined as something too all encompassing. It is always defined inclusively of all the business processes, goals, objectives, technologies assets, etc of an organization. It’s almost defined as something that isn’t valuable until it is complete at all of these levels.
However, this causes immediate problems that are reflected in every analysis of enterprise architecture (or failures in EA effort) that I ever read. It always appears to be that EA efforts fail because they are not maintained, through ‘lack of governance’, or that they are misunderstood or ignored by senior management.
Analysis of EA effort actually spent is one thing, but other field reports indicate that the effort never even officially gets off the ground before it’s too difficult to define the ROI of the investment. Nobody seems to question the ROI of dedicating resources to blocking and passively obstructing enterprise architecture efforts but that is another issue altogether.
I think the solution to these problems is very simple. It’s a solution that eliminates the high-cost of enterprise architecture initiatives (and therefore the issue of ROI), it also helps incorporate enterprise architecture efforts into the rest of the organisation (therefore making alldesign effort enterprise architecture effort), and it takes enterprise architecture to the board room (or at least the CIO’s office) where it belongs.
The three fifteen step plan for solving your enterprise architecture issue is as follows:
The most important step here is that you are no longer defining EA as a complete, integrated, end-to-end, endeavor. You enterprise [business] architecture is complete by step 7 above. It’s done. The assumptions about how value in the enterprise is generated are defined. The definition of enterprise architecture is also re-defined as only the enterprise [business] architect + the planned traceability to other key assets. In this sense, your EA is complete.
Steps 8-10 ensure that your enterprise architecture is always up-to-date. But up-to-date shouldn’t be read to mean complete. The EA is up-to-date in the sense that the enterprise [business] architecture is up-to-date and you know the status of all traceability. Within the status of the traceability is the key to understanding how complete you understanding of systems is – including the completeness ‘alignment’.
Steps 11-13 ensure that the information in the EA is known, understood, and utilised for decision making. Steps 14-15 ensure that the enterprise architecture (and the enterprise architect) delivers value. It also allows for additional specific, targeted EA effort to be managed through the normal project approval processes.
If the following steps are followed – and this of course depends on you finding a ‘real’ enterprise architect to hire – you will be well on your way to best practice in enterprise architecture. More importantly, the communication and organizational engagement issues will be solved. If you have hired correctly, the enterprise architect will also be an enthusiastic and invaluable member of the IT management and / or executive team.
As far as EA becoming more valued than ‘management’, I’m not sure when this will happen. But if we can stop whining about how difficult it is to get EA established and get on with the job (see above process) we at least won’t need to defend our failed efforts anymore.
There is something particularly exciting about Barack Obama’s plan to appoint a government chief technology officer. Not only is this good for government, but it’s also good for the IT industry. Like Ron Tolio of Cap Gemini has said:
No half measures. And quite a strong message to many corporations that struggle with the role of IT in business. This is far from the marginalised position of an IT manager who apathetically reports to the CFO about cost cutting and risk management. This is a boardroom position, one that is supposed to create strong impulses for change and growth.
There is a real difference between a CIO that is charged with ‘serving the business’ and one that is charged with ‘getting value from IT’. You can serve the business by saying ‘it’s the business’s money therefore they get to decide how to spend it’. But to commit to delivering value out of IT you have to commit to business benifits and a business return of technology spend. You need to actually contribute to the strategy and deliver growth through technology spend.
It doesn’t matter what type of CIO you are. As long as you know what is expected you can be successful. But if you are successful purely because you have moved investement decisions to business units, who is ensuring that you are getting the most value out of IT? Is IT actually contributing to the organisations strategy and growth?
Anyway, it’s also good to see a few of these sites popping up too. ObamaCTO.org allows anybody to suggest ideas for the CTO role, which are then voted on and ranked. Now this sort of system is still susceptible to manipulation by special interests. But it’s transparent – and that’s all you can do.
The Enterprise Architecture Network Google Group has soon good disucssions. Though it sometimes goes beyond what I would strictly call ‘enterprise architecture’; but most EA discussion do. I would recommend joining it to connect with other architects. You also have to be a member of the related LinkedIn group.
More for my own reference, here is a contribution I made to a recent discussion on the difficulty in determing an ROI for an enterprise architecture practice:
HiI think it’s unfortunate when we are asked for an ROI for developing a EA practice. This is like asking for the ROI of having a project manager. It’s probably a good question, and I’ve asked it myself, but some things need to be sacred so we can just get on with the job.
I’d never ask for the ROI to set up an EA practice – to me this is sacred – because I’m sold on the idea already, as long as it’s small. I think we need to sell EA more so less people ask for an ROI. But I also think that means changing slightly how we currently define EA. It also means we need a response when people ask for an ROI…This is why I’m so interested in how we define what EA actually is. I think we should define EA solely as what some on this group might call Enterprise Business Architecture (EBA). The other deliverables, work products, initiates, etc should be traced to that EBA but we shouldn’t call that the EA. We also shouldn’t say the EA is complete only when all of the IT components properly align to it. We should simple do the EBA – showing value streams, key customers, service strategies for the enterprise, etc – and trace to the minimum asset types required to get calculate baseline alignment to the EA.
The reason I say this is because you can’t define a return on investment for developing an EA practice except in terms of improving decision making relating to IT investment. You are looking to improve alignment to the EBA over time, but you can’t do that from the EA practice itself. You can only do that by influencing IT investment decisions. Unfortunately, a more general tool already exists for improving decision making relating to investments. And that’s the ROI calculation.
The problem is nobody ever asks ‘What is the ROI of determining the ROI?’, nobody ever asks the question ‘What is the quality of the ROI calculation?’, and nobody ever asks ‘How is the ROI process performing?’. There is a bunch of IT effort being spent which roles up into the ROI calculation and unless you think your IT systems couldn’t be any better at this point in time, it’s not working.
Whether it’s formal or informal, organisations already think they are making decisions to maximize return on investment. The problem is, in the area of IT investment there is no formal method of determing the inputs which go into the calculation of return on investment. Also, the inputs must take into account the value streams of the business, IT costs, changes in IT cost structure, and changes in business cost structure. IT initiatives move costs into IT while creating activities/costs to be performed by users outside IT. As such, IT can’t determine ROI itself because the initiatives transform more than just the IT organisation.
An EA practice should formalise that process of determining the inputs into ROI calculations. It should also allow the performance of that process to be managed over time. By the way, within the phase ‘IT initiatives’ I am also including that particular type of project I like which is technology-enabled business transformation.
Other initiatives – business initiatives – simply need to include the costs of IT in their ROI calculation. IT cannot, by itself, commit to all ‘returns’ which are outcomes of IT initiatives. This doesn’t mean IT can’t run business transformation programmes. It simply means that any initative of this type requires communication, traceability, and modeling across multiple disiplines. And it needs this even to calculate the ROI.
EA, in the strict sense of Enterprise Business Architecture, is the basis for not only IT strategy, but also for IT investment decisions. EA, in this sense, is the baseline level of knowledge and process required to make ROI calculations for other IT initiatives. So asking for an ROI for and EA practice which analyses the value streams of an enterprise and traces these to technical and organisational components is like asking for the ROI of developing high quality ROI calculations.
By the way, it’s possible that a particular CIO doesn’t have the responsibility for delivering value from IT investments. In some instances the IT function doesn’t technically run even IT projects. Instead these projects are ‘business projects’ relying on IT only to deliver a defined set of IT services. However, this is a dangerous position for a CIO to be in. It also just means that the EA practice should be sponsored by somebody else who does have that responsibility. It doesn’t mean that (a small) EA practice shouldn’t exist.
Regards,
Matthew De George
Powered by WordPress & Theme by Anders Norén
