I.T. gets a bad wrap in some information management initiatives. I prefer to take the approach that many IT disciplines are helpful for better information management. The shift from I.T.’s perspective often looks like this:
Category: IT Management Page 1 of 2
Great article on patterns by Kris Meukens here.
My slightly self-indulgent reply is below. I’ve always been fascinated by how our understanding of IT and organisational design in general seems to follow the same path of Christopher Alexander’s works on the design and architecture of the built environment.
—
I think it’s interesting to see the parallel and delayed timeline between “patterns” as they evolve in built architecture theory, versus patterns in IT.
I’m not an expert in either but I see the history of patterns in built architecture through the lens of Christopher Alexander:
- Notes on the Synthesis of Form (1964, year 1). Starts to describe what later came to be known as “patterns”.
- Notes on the Synthesis of Form – Preface to the first paperback edition (1973, year 9). Already starting to rebel against those who focused on “design methods” as a meta study and assets “I reject the whole idea of design methods as a subject of study, as I think it is absurd to seperate the study of design from the practice of design”.
- A Pattern Language (1977, year 13). These are fully formed patterns with the notion that they can be combined to create designs. It’s not a simple mix and match – still leaves room for a design process.
- The Nature of Order (2003, year 39). Doesn’t exactly reject patterns but focuses on wholeness, a set of qualities, and a set of structure preserving transformation that help designs unfold.
- The Battle for the Life and Beauty of Earth (2012 – however focuses on 1985, year 21). This focuses on two world views that he saw as in battle – one of which was opposed to his style of building.
Reading “Battle” in particular makes you feel our current understanding of patterns and our obsessions with Agile, Design Thinking, etc mean we are in the equivalent of year 25.
Reading the above article feels like we’re heading towards the equivalent of year 30. I mean this as a compliment.
Good article, including the simple fact:
In the industrial company of the future, there won’t be a separate IT department.
From: http://www.strategy-business.com/article/The-Thought-Leader-Interview-Bill-Ruh?gko=9ae51
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.
I would have loved to have seen the presentation that’s been given some positive press here. Westpac are putting some meat around their transformation agenda after having learnt from the experiences of other banks.
Many of these large scale transformation programs (think ERPs, CRMs, core systems replacements, etc) have a tendency to teach the organisation about a product. The whole organisation will learn how to implement that product – they’ll learn it’s strengths and weaknesses, and the right and wrong ways to successfully exploit them. Those in the organisation who aren’t part of the solution will at least learn that they have an opinion about these things.
Now, the actual benefits of these programs aside, this is a strange way to for your organisation to spend a few years. These programs become a distraction that take up executive, management, and operational attention. But what if you changed the conversations so that rather than learning about a product, you completed the same program but what you where really doing was learning about your customers and how to better orientate your organisation towards their needs?
I think the approach Dave Curran has managed to convey (again, based on the reporting – I wasn’t there) starts to do that. This approach means that effort is first and foremost about the customer. Now I’m the first to say it’s not that simple. There is still a lot of work to make that vision operational. But it completely changes what the organisation will primarily be learning during program.
The key lessons now will be about customers – what Westpac knows about them, what they don’t, what decisions they are making every day, and how that might be understood by Westpac staff when making their decisions. The other lesson they will be learning is how technologies they already have, combined with technologies available in the market, can be used together to support various customer scenarios. Not trying to find “the best” solution without any context, but trying to design solutions across a well informed view of what is important to customers.
I think too that if this is done right, the discussions won’t be broad sweeping generalisations. They won’t be “is this one monolithic system really customer focused?” Likewise, there shouldn’t be that tendency to continuously revert to “yeah, but what is a customer?” That conversation seems out-of-the-box but is typically only asked because the people in the room have never met a customer (!) so they revert to broad open questions rather than use their experience.
Done right, this approach will draw out rich, informed conversations that admit that we have to bring components together to support specific customer scenarios. It will draw out conversation about what we don’t (!) and ensure we find out. Done right, this approach keeps up the sustained momentum these programs need to do the hard work that will truly transform the organisation.
I have a few grounding concepts that I think are relevant here. They are quite simple in their nature but powerful as the basis for governing change. I’d suggest these should be established for the program.
The Customer Advocacy Office
We talk about the importance of customers all the time but often the question we don’t ask is “what is the business unit in our organisation that advocates for our customers?” I don’t mean lets give somebody the responsibility for customer and then split the role into “Contact Centre” and “Web site”. I mean real, serious thinking about customers. Being able to understand and back up with facts. Being able to offer targeted operational changes – backed by evidence – that will improve the experience of customers.
Customer Experience Campaigns
Your organisation is probably comfortable with marketing campaigns. But what if the concept of a campaign was expended to include any situation where your customer had a defining positive or negative experience with your brand? Customer Experience Campaigns apply the basic concepts that are used to manage a marketing campaigns to all of the individual experiences of your customers. This is actually really difficult, and really important. And it’s what we mean when we say we want to be customer focused – but do we actually do it?
Customer Information Management
There is a lot of work required to get a single view of a customer. There is even more work required to repurpose that view so that it highlights the information required for different groups to make decisions (i.e. single core data, multiple views). But that’s still not “customer information” – that’s just consolidating and presenting data effectively. A true responsibly for customer information management means knowing what you don’t know about your customers, and understanding the value of finding out. It also means understanding how modern technology allows us to understand and predict the complex decisions that our customers are making by using big, social, cheap, integrated data to act as a proxy for intimacy when you can’t always get inside your customer’s heads.
Customer Return on Operations
Things like Net Promotor Score (NPS) are great but they are the tip of the iceberg when it comes to using customer-driven metrics to improve your organisation. These “voice of the customer” metrics are great but they are “lag” indicators until you do the correlation required to make them “lead” indicators. Measuring you customer return on operations combines how your customers think you perform with how you think you perform. It’s hard, it takes a prolonged effort, but who could argue that it’s not important?
Competency Centre -based Business Transformation
Many transformation programs are top-down. This means they are limited to the types of transformation that you can achieve top-down. The Westpac approach will required a middle-out approach. There are many functions within the organisation that will need to be transformed to execute on the vision. Thankfully, competency-centre based business transformation is an excellent alternative to top-down transformation – if your transformation team “gets it”.
This approach also includes the question of which type of “core” you want your organisation to have (accounting, versus product customisation, versus customer hub). When you’ve done the right homework, you can then make clear and informed decisions on whether something is differentiating or not differentiating. This decision drives standardisation but it is so mixed up in a tight bundle or current power struggles it needs an informed third party to arbitrate.
I’m not saying just talk about the concepts above in the executive management team. I’m saying that in addition to the other governance required for this sort of program there are executive roles for each of the above areas. There are charters and terms of reference for each of the above areas. Each of these areas should be managed as a business capability where the executive in charge is responsible for working across functions so that the people, process, information, and technology all work together to support the capability.
By the way, I’m not sure I get the title “Dancing About Architecture” that the article I link to above uses. I’m assuming it’s a reference to the “Writing about music is like dancing about architecture” quote that I, like everybody else, mis-attributed to Elvis Costello until I just looked it up. It’s a nice image – the idea that you might use something other than architecture (such as your customers) to guide the direction of your architecture. You dance around (or “about”) your architecture so it knows where to look. Though by alluding to the music quote the author seems critical of the approach. Anyway – looking forward to part 2…
As per linchpin project #9 (“Project 9. IT federation: shrinking corporate IT and embracing shadow IT”) we need to view our success in terms of capabilities not functions – and remove any roadblocks to maturing our capabilities.
So this is happening:
Big data: Why IT departments mustn’t be a drag on analytics | ZDNet: “‘Technology functions are still finding it difficult to keep up with business demands. Working in analytics and being responsible for analytics, I can’t let that happen,’ said RBS chief analytics officer, Customer Solutions Group, Alan Grogan.
‘I can’t turn around to my CEO or to my customers — or even just if I want to retain staff — to say ‘I’m sorry, we just don’t have the scalability, the flexibility or the control on the domain’.'”
At the same time, there are efficiencies in building a federated IT capability. When Analytics teams need to manage their own IT they aren’t evolving the IT function. And when Analytics teams manage their own IT the IT function has to evolve. There is a joint responsibility to manage this process.
The language of IT alignment has to end. It’s no longer serving any purpose except to isolate disciplines that no longer need to be managed in isolation.
The convergence of the commoditisation of IT and the socialisation of business means that IT in its strictest purest sense has won. Paradoxically it also makes IT completely unimportant as a competitive differentiator.
IT is available cheaply to anybody who wants it. IT can be acquired easily in packaged form, or as a service, through any number of cloud or “… as-a-service” vendors. Many would argue that this doesn’t solve all problems – but to quote the old joke about alcohol, neither does milk.
For IT systems that are not easy to acquire there are strong incentives for IT service providers and outsourcing organisations to build them. You might pay more than you’d like but that’s because it’s hard to manage these guys not because of any real scarcity.
The so-called socialisation of business is a trend that slightly trails the commoditisation of IT. In fact, the consumerisation of IT appears to drive both. While it might have once been the IT departments job to drive adoption of IT to improve efficiency this is no longer the case. IT departments are now more likely to be seen as holding back the adoption of IT.
So why does this mean the end of business and IT alignment? Because there isn’t any “business” and “IT” to align! It’s always been a misnomer. Firstly, IT’s view that there was “us” in IT with all this complexity and then there was one bug lump out there called “the business” was always a farce. “The business” was just shorthand for a generic “them” that moved and shifted like bad requirements.
On the other side there was “The business” – rich and complex and important. In “the business” there were performance incentives, real customers, governance considerations, all that important people management and cultural change, etc. But this side of the fence had some delusions too. Over the last 20-30 years much of the value that business units mentored was shifted into IT systems. But unfortunately this meant managers thought it was shifting to IT.
When I asked who is responsible for the information in the IT systems during a recent meeting everybody in the room pointed to the IT guy. When I clarified and added that I meant the real details of what the information means they still – and they always do in my experience – pointed to the IT guy.
You see somewhere along the line people started believing that if something passed through an IT system it was suddenly owned by IT. But it got even worse than that. Because these “IT alignment” problems went on for so long, and nobody ever fixed them, and because IT was the service provider and “the business” was “the customer”, the IT team compensated.
So not only did everything that pasted through an IT system become owned by IT, everything that was “detailed” became an IT problem. Let me explain. The thing with IT systems is that they persist. If you have a human system you need to teach the new humans the system so the system can continue to operate when the old humans leave. This process keeps the system alive. IT systems, except for some overworked back-end humans, don’t need this. IT systems continue to operate regardless of the passing of knowledge to new humans.
Over time this has meant that where systems are built on technology the detailed knowledge of the system are lost. Nobody knows the details of the system. However, when things went wrong somebody had to find out those details. The IT groups had the keys to the back-end of the system so were able to find out how the system worked.
Even though IT people could find out how the system worked it didn’t mean that they were the cause of the problem. Sometimes the world had changed and the system didn’t work in the new world. But at the end of a long investigation the only person who could fix the problem was the one person who had spent time looking at the details.
This process had an interesting effect on the users of IT systems. Not only did they think that things that passed through IT were now owned by IT, but they thought that “the details” were owned by IT. In fact, I think that in many contexts the term “technical” and “detailed” have become interchangeable.
I’ll skip over the process where all of the people with “technical” knowledge – including detailed knowledge of “the business” – were outsourced. That’s just progress – it’s done – get over it. But it’s an important step in the story. Because it’s now possible to acquire the IT components of your business easier they are no longer a competitive differentiator. Trouble is because the IT components still have value, and your competitors can acquire them, they are a business imperative.
To actually differentiate you have to do what you’ve always had to do, build hard-to-replicate capabilities that combine people, process, information, and technology. It’s the integration of all of these that creates value. So why all the talk of “IT Alignment” in the first place? Who knows! Growing pains?
So, What’s next?
Because IT is easy to acquire, and because business units can’t seem to manage the details of how their processes operate, and because it’s integrated capabilities that drive competitiveness, a complete governance change needs to occur. It is no longer effective or necessary to have a primary governance separation between business functions and IT.
But hang on! I could also track a whole history of cross-functional collaboration within organisations. Every single problem in every single organisation appears to be solved by “a cross-functional team” right? In fact, the whole structure of management education has become about educating future managers that a. All organisations are made up of common functions (IT, HR, Finance, etc) and b. that their job as managers is to coordinate across these functions.
This process, that builds organisations in which every collaboration of value is an exception and then creates managers who are rewarded for intervening is bullshit (!). Our governance models need to change.
The thing that needs to change first is to give people responsibility for capabilities. The end-to-end responsibility for something regardless of the separation between “the business” and IT is the very first step towards “alignment”. If you haven’t done this stop working on alignment issues until you do.
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.
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.