Matthew De George

Part of The Beginning and The End of Information Management.  Now available for pre-order on Amazon.   

---

We live in the future. But we hold onto past ideas for too long. One of these ideas is that we should think of business processes before we think of technology or data.

This isn’t true. We should think of value, outcomes, markets, and a whole bunch of other important things and all of them are more important than technology by itself, data by itself, or business processes by themselves.
We have built functional organisations and filled them with people. So we’re going to get some perverse outcomes. People are good at that. It’s what makes our organisations interesting.

We spend so much time telling each other how business processes are more important than technology and data that it starts to feel like a discussion about value. But it’s not. Business processes, technology, and data are all equally important or unimportant. Each of them is only the most important thing to the functions and silos who are responsible for them. And there are only functions and silos responsible for them because that’s how we design our organisations.

But in modern organisations there are business processes, and types of business processes, and indeed whole business models, that can’t operate the way they are designed without the associated information technology. Likewise, all business processes depend on, generate, or coordinate with other business processes through data.

This means that at some level the idea that business processes “comes before” or are somehow conceptually “above” concerns about technology land data is no longer valid.

Justify the value of data

Imagine talking to the CEO of a nuclear power plant. You might say:
“Look, uranium is obviously critical to what we do around here.”
The CEO would nod in agreement or at least impatiently stare you into making your point.

“Well we’ve done a bit of a review and we’ve found some issues with the handling of the uranium. In fact, every time somebody goes near it we find it spreads. The Geiger counters are picking up radiation all over the plant.”
The obvious analogy here is with data: both critical to the operating model of most companies but also potentially risky if handled in the wrong way.
But if this situation played out like most data governance conversions it would continue like this:

“Okay, I know uranium is important. But what is the business value of it?” CEOs ask these sort of open-ended questions to uncover what you know, so this isn’t unusual.

“We it’s fundamental to how we operate. It’s a critical resource. Actually, because it’s a critical resource the way we manage it should be considered an asset. So these machines help us process it and the plant uses it to make power.” You’d feel like you are rambling now – and it’s not a very satisfactory answer but given this is a fundamental part of the operation of a uranium powered plant it’s actually hard to know where to start.
The CEO isn’t uninformed about the operations of the plant so he offers “So we have a cleanup crew for uranium incidents. I spend hundreds of thousands of dollars on this each year so I hope I’m getting something for it!”

This wasn’t where you’d start the conversation but it’s as a good a place as any so you offer “Yes, well that’s once something goes wrong. We need to be more proactive than that.”

“Yes, we need to be proactive. We want to innovate because our strategy is to be a leader in this area.”

“Great – yes – so the cleanup crew can help us once there is an incident but how do we ensure we handle the uranium in a way that reduces incidents?”
“Well we just switched suppliers so we’ll need to give them time to bed down their processes. They have productivity targets built into the contact so we should expect them to be more productive each year. Well they have to or I’ll cut orders from them! We wont tolerate breach of contract.”

You know that the supplier only handles the uranium to the delivery point, and the delivery points seem to be well controlled. Actually, there are a lot of controls in place, but some of them aren’t being followed, and some just don’t seem feasible to follow.

“Our suppliers aren’t the problem, it’s the way we handle the uranium after its delivered. Actually, there is a regulatory element to this too…”
“We want to be compliant!”

“Yes, but the readings we are getting all over the plant indicate that our handling may not be compliant”

“Darn regulators!”

“So let’s try to get compliant but at the same time let’s see if we can get business value from the compliance. There are a lot of sick days maybe they are related to the poor handling of the uranium.”

“I think that’s a cultural problem” the CEO is again attributing common actions across a large group of people to “culture” when you think he might mean “incentives”. But that’s another conversion. Anyway, he’s still talking.
“We need to get business value out of this initiate. I know uranium is important but what is the business value we are going to get form this initiative!?”

“Well at first we just want to contain the issue”

“What’s the ROI?”

“Well it reduces risk”

“Our risk appetite it low at the moment”

“So just to contain it we’ll need to slow down movement of the uranium at critical points and refurbish these damaged containment areas”

“How much will that cost?”

“$2 million”

“Well that’s a lot we don’t have that sort of budget allocated. These things always blow out we started an initiative 3 years ago and it was supposed to be $500k but it blew out to $800k”

“Well, actually this is just the first thing we need to spend, we’ll need to spend a lot more once we have a roadmap”

“I think we should do a roadmap first before we contain the uranium”
At some point in this conversation it’s the CEO that needs to be removed, not the data management consultant (Sorry, the person responsible for the uranium).

An important point: there is somebody in this fictional tale responsible for the uranium and having this discussion with the CEO.

Even if the conversation isn’t getting anywhere there is at least a significant budget allocation, a policy and process library, and a broad understanding across the plant about the dangers and proper handing of the uranium.
So if you’re having bizarre conversations like the one above – and they are about data, and not uranium – you’re at least trying to ensure that the value of data is understood.

But you’ll get into difficulty if you have to answer questions regarding “the business value of data”. The problem is not finding business value of data, the problem is realising that data has business value.
Data has a primary value.

Data isn’t only valuable because you can do specific things with it. Instead it’s valuable because you can’t do certain things without it. If you aren’t valuing the data you aren’t valuing the things you can do with it. If you have a car, and you want to drive it, you need wheels. The tires on the wheels need to be maintained. The business value of the wheels is the same as the business value of the whole car.

It’s hard to make an organisation think this way without sounding like what might be called “a data geek”. But it’s an important part of the transition you need to make into a data-driven organisation.

No organisation attempts to operate without people, but nobody asks “what is the value of people?”. We do have a variety of ways of managing people; including both disconnected performance management systems as well as a general consensus that all interactions people have with the organisation constitute a continuous feedback loop. But we’d never try answer such a general question as “what’s the value of our people?”

I.T. departments are unfortunately stuck in a service posture. They are stuck in the position of having to justify why something is important. You don’t need to do that for data. People know it’s important – when they ask about the value of data they are just messing with you.

I’m starting to build up my thoughts about how society and the mind evolve together.  

For starters, I think we need to consider the possibility that what we think of as “emotional” versus “rational” thought might actually be the same thing.  

If we consider how our minds evolve based on interactions with others it makes sense that we might have built up this distinction in order to manage interactions with other people rather than because they are different inner realms. 

Thoughts are in Notion here.

At Aware we want to create something special – something that endures. To do this we need a strong core that binds us together even as industry trends, best practices, and technologies change over time. How we navigate and respond to the various trends and fads we encounter is part of that core.

Things change, and much has been made of the need to react to change. But we don’t like the word “react” as it’s too limiting. Our relationship to change should go beyond reacting. We also want to be able to effectively drive change, and to hold back from reacting to change that isn’t going to be enduring (i.e. we want to know a “fad” when we see it).

We find two questions help us craft the most effective response to a new fad. First we ask “What if it’s truth?” and then “What if it’s half right?”

What if it’s truth?

This question takes the extreme position that something universal and enduring might be embedded in the fad regardless of whether the fad itself turns out to be important.

For this new fad to become popular amongst all the other ideas in circulation it must resonate in some broad or universal way.

While it might be a waste of time to react to a fad that turns out to have no enduring impact on society, there is still value in engaging with the core truth that made it a fad in the first place.

Take the current trends towards AI and machine learning as an example.

The robots are coming… is a metaphor for the impact of technology on society

We all feel the robots are coming. These robots are the embodiment of our daily experiences: our trepidation when encountering the new, our struggles to use new versions of our computers’ operating systems, and the experience of having to learn new skills when parts of our job are automated to sent off-shore.

Depending on how we define robots, the robots are already here. All of the talk of “artificial intelligence”, “machine learning”, and robots is less about availability of different technologies and more about how these technologies are impacting how we organise our businesses, customer experiences, and societies.

So at Aware, we work at the intersection of the simple, easy-to-use capabilities available at marginal cost from technology vendors and the significant impact the availability of these capabilities have on how we manage operations and customer engagement.

What if it’s half true?

Once a fad is in circulation it becomes hyperbole. If you scale down the expectation you also get a sense of how to response to the fad in a way that reduces risk.

Human + robot beats human or robot every time

Consider the example of AI and machine learning. Blended or hybrid operating models will always proceed all-robot approaches. This is partially because the way technology improves and is embedded into existing operating models means it typically replaces part of a job before it replaces a whole job.

We also know this because we can see the way early, high-profile successes in AI have evolved. The work of Garry Kasparov (and others) in “advanced chess” and “freestyle chess” is a good example. After Deep Blue beat Kasparov in the late 1990s Kasparov moved on. He experimented in new rules for chess competitions where different combinations of collaboration between humans and machine could be explored.

So at Aware we focus on blending the best of what humans can do with the best of what robots can do. We encourage personal relationships with enabling technologies that have direct impacts on the productivity of individuals and teams.

Conclusion

If you want to creating enduring value one thing you’ll need to do is navigate the trends and fad you encounter along the way. Ask two questions to help you craft your response: “What if it’s truth?” and “What if it’s half right?”

An unashamedly technology-linked view of things.  But only because it is impossible to make a business case for compliance without using enabling technology.  See: Embedded Compliance (draft)

Protecting your customers’ data is at the intersection of three organisational competencies that companies already struggle with. Together these amount to a lack of what we might call risk empathy.

Risk empathy is the ability to feel the risks that others face. It’s clear that this is a struggle for many organisations. British Airways (BA) may well be the first high-profile test case for enforcement of the EU’s General Data Protection Regulation (GDPR) but it won’t be the last.

While you might say GDPR only relates to citizens in the EU, the essence of BA’s record fine is a failure to protect personal information and payments data. GDPR certainly offers the most aggressive regulatory protections for these types of breaches, but similar protections are already in place in other jurisdictions – including Australia – and the trajectory of regulation is clear.

In any case you shouldn’t think this-wont-happen-to-us. The core organisational deficiencies that impact your ability to feel risk empathy are familiar to many organisations. If you want to improve your ability to feel risk empathy you have to solve the following organisational challenges:

1. Organisations are traditionally not good at managing the risks relating to the conduct of others. Take, for example, the issues raised during the Banking Royal Commission around conduct risk and our ability to guarantee all parties are working in the interests of customers.
2. Data management itself has also been a challenge to many organisations. Data governance discussions too often begin with the creeping realisation that “we thought that was somebody else’s problem…”
3. Organisations are not good at managing risks they don’t own – or rather that aren’t explicitly represented in the executive accountabilities that would ensure risk mitigations are properly designed and funded.

Data breaches are right at the intersection of these challenges.

In the case of British Airways data was stolen. A third party had to commit a criminal act – but it’s BA that must pay the price.

This is different to the Cambridge Analytica case where the problem was primarily that Facebook and its partners configured features under their control to share data beyond the consent obtained from its customers.

BA’s fine is GDPR’s way of pricing this type of risk. It is a call to consider the risk to the individual who is actually the subject of the data.

Managing “data subject” risk is different to managing other risks an organisation might face. If a risk impacts your organisation you might choose to accept the risk, or perhaps cultural deficiencies might mean the risk is never even raised. There is also a personal risk involved – if the risk event occurs somebody in the executive team will likely be held to account.

But when data subject risks are discussed you have to remember that the data subject – your customer – isn’t in the room. Somebody has to speak for them with a voice that is strong enough to get your organisation to act differently.

We missed something in the spectacle of the Royal Commission. Sure, it’s fascinating to watch what we think of as rich and successful figures struggle. But these are real people doing a difficult job. What the RC also revealed is that managing large organisations is hard.

As commissioner Haynes himself did multiple times during the commission, we need to make an important distinction. On one hand there are all of those omissions, negligent behaviours, and people not knowing things they clearly should have known. The distinction between these things and a deliberate decision to commit a criminal or unlawful act – either as an individual or an organisation – is important.

Breaking the law is obviously wrong and at the very least different to situational incompetence. But it’s on the other side of that distinction that the interesting business of running a global bank – or any large organisation – occurs.

Think also about the line in between these distinctions – or rather the same distinction but for the actions of others. Things like detecting criminal activity, or ignoring it, or having an obligation to not create environments that might incentivise the criminal acts of others. This is genuinely difficult.

We might sometimes think it seems like executive roles just go to the people who want them most. We interpret this in all sorts of ways like ambition, and greed, and politics. But there is an institutional side to this dynamic too. It’s that our organisations are near impossible to manage.

You might be able to manage your place in an organisation. At any level of any organisation you know when this is happening: that’s not my job, we need to do that but we don’t have time or budget, not my problem. But when that process happens at an executive level it becomes: only let me know exceptions, only the top 3 exceptions, that will negatively impact financial performance, and that’s not what I’m focusing on this quarter.

You can scream “but it’s your job to be across everything!” all you want. The question is how?

The leaders in our major organisations typically get paid well. Some of us might question whether they deserve it – but those people tend to question it based solely on competence or based on their view of the institution as a whole. This is niave in at least two ways.

If you don’t understand the value of an effective free-market banking system you don’t really know your history and have likely never tried to build a small business without a loan.

Secondly, you’re naive to think the salary is only priced on competency. Maybe the risk of sitting in front of a royal commission was always built into the salary. At any rate, the management is there to free the owners from lots of difficult and time-consuming decision-making. Part of the purpose of the role is to act as a buffer against a problem we haven’t yet solved.

So the missing lesson is that we genuinely don’t know how to manage our large organisations. Particularly, if by manage we mean full, multi-dimensional management that takes into account all activity and all the economic, community, and moral impacts of the organisation.

I have some ideas about this – I’m sure we all do. As a hint – I don’t say “Information Management IS Management” for no reason. But the discussion we have to have is how we build real management systems that augment the people who are responsible for the management of our organisations.

I remember a Nonconformist manufacturer, in a town of the Midland counties, telling me that when he first came there, some years ago, the place had no Dissenters; but he had opened an Independent chapel in it, and now Church and Dissent were pretty equally divided, with sharp contests between them.

I said, that seemed a pity.

“A pity?” cried he; “not at all! Only think of all the zeal and activity which the collision calls forth!”

“Ah, but, my dear friend,” I answered, “only think of all the nonsense which you now hold quite firmly, which you would never have held if you had not been contradicting your adversary in it all these years!”

– Culture and Anarchy, Matthew Arnold, 1869

Part of The Beginning and The End of Information Management.

The 30 Year Drift

Something strange happened when the discipline of general management met information technology. While a lot has been said about the impact of technology on our organisations, hardly anybody even noticed the subtle drift that was occurring in all of our organisations over the subsequent 30 years.

The question of who is responsible for the data in our organisations shouldn’t be difficult to answer. The fact that it often is shows how it feels to be at the end of the boiling frog analogy when you’re both the scientist and the frog – and you think you’re still home safe in bed.

As a side-note I’m not fond of analogies. The explanation is a little long-winded but basically I think analogies make people feel like they now understand each other more without actually improving their understanding. This, to me, is worse. My dislike for analogies means two things. Firstly, I’m not very good at them if I’m honest with myself. Secondly, when I encounter them – when people force them upon me – my immediate reaction is to try and get to the point where the analogy becomes absurd and unhelpful. You have been warned.

On with our story. Over the last 30-40 years information technologies have been radically integrated into business processes and business models.  At the same time, the relatively new discipline of software development has evolved and matured in order to keep up with the capacity, quality, agility, and speed-to-market improvements that business’s dependence on I.T. has demanded.

As these two trends collide, the importance of the software development discipline to the average organisation has peaked.  Pure software development, no longer a core competency of the average organisation, is now a commodity.

The paradox is that while software development is now a commodity the need to integrate information technology into business models is more important, and more difficult than ever.  Add to this the oft-sighted failure rates of large corporate I.T. projects and it could be said that while software development is a commodity, successful software development is scarce resource!

Less cynically, the real lesson that has been learnt is that successful software development is only possible within the context of a clear understanding of the business needs that drive the software development effort and the business changes that are implemented alongside the development effort.

Software development has been commoditised precisely because successful software development, and a successful IT function, must be managed within an overarching continuum of service-based management disciplines, outsourcing contracts, technology-enabled business transformation programs, and business knowledge.

So the history of the last few decades of the I.T. industry has been to learn that successful business I.T. requires an understanding of the business.  Unfortunately, this can be as a profound a lesson as it is practically meaningless.  It’s like learning that a hand must fit a glove or that a successful puddle is made when the water exactly aligns with a hole in the ground.

My point is that technology people have been rigorously defining an approach to their discipline over decades. But it’s impossible to define a pure technology discipline without understanding business context. So I.T. people have defined things like enterprise architecture, business architecture, and value-seeking frameworks that attempt to go from business motivation all the way down to code.

So I.T. now has processes and frameworks well beyond what it’s their job to manage. This can only lead to frustration on both sides.

At the same time that I.T. people where perfecting their disciplines, information technology was being applied all over our organisations. With all the current talk about robotics and automation it’s easy to forget the automation that has already occurred.

When on payday you see that your leave hasn’t been correctly processed that used to be the job, and therefore the fault, of a real live human. So you could go to that person and talk to them about it. In a real sense you could say somebody in payroll messed up. Today that would most likely be described as “an I.T. issue”. In fact, despite our ability to also find a way to blame just about anything on human error, it most likely really is an I.T. issue.

While they weren’t trying to develop overarching approaches to get from business motivation to code, I.T. also developed mechanisms to ensure that technically, even an error in an I.T. system was actually an error in a “business requirement”. This externalised I.T. problems into problems in “the business”. It didn’t really matter who in “the business” was responsible, as long as it was somebody outside of I.T.

So when we think something is “an I.T. issue” we are both assuming that just because something is automated the responsibility for it shifts to another department, and we are forgetting that I.T. departments have been putting up with this for so long that these sort of failings don’t even appear in their key performance indicators.

Even if I.T. people had developed a complete approach to ensuring these problems never happen (they haven’t, by the way), by definition this approach would need to include the elements of business context that make the technology components work. You can’t understand if an I.T. system is working correctly unless you also model the context of the system.

If you have an approach that claims to manage everything good luck! Because you aren’t responsible for everything so not everybody will listen to you. This is the situation I.T. departments find themselves in. But because they aren’t responsible for everything they’ve never had to truly test if their over-arching approach works. They don’t have the span of control to make this sort of system work.

So with the best intensions I.T. people go about using the parts of the framework they can control and assume the parts they can’t control are operating as they wished they would. But the parts they don’t control aren’t working the way they assume they do.

Everybody does this, so it’s okay. I’m not blaming the I.T. people for doing as much as they can within their span of control. I do, however, have a problem with some of the practices introduced under the banner of “agile” which actually change the relationship with other business units again. The level of accountability that most agile approaches surreptitiously push to other business units isn’t something that should be implemented by stealth. That perhaps is a topic of another book.

Over on the side of the business units outside of I.T., from their perspective there has been a lot of jobs lost, a lot of computerisation, and a lot of shifting of things that used to be done on paper to now being done “in the computer”.

The shift of a process to a computer isn’t without other organisational impacts. Before you might have your own personal system for filing away your sales leads. Now, you’re likely to have to conform to a system imposed by others (and enforced by the computer). So all around us we are co-working with computers.

It’s natural to blame our co-workers for mistakes that are their fault. So we blame the computers. But that feels a little silly or at least premature in a world not yet dominated by robot overlords, so we blame the I.T. department.

But there are plenty of ways an I.T. department might respond to this logic, some of them legitimate but all of them requiring deep debate:

1. If the I.T. department doesn’t receive requested funding, or in fact doesn’t even have it’s own budget, can it be blamed for the errors and issues on the margin that it can’t address?

2. If the I.T. department can fix a problem, as long as you tell them about it and how to fix it, does that mean they aren’t responsible for the impact of the problem before they were told about it?

3. While I.T. departments run computer systems, they will always have a nominated “business owner” for those systems. So isn’t that business owner the one ultimately responsible?

As the software development discipline has evolved the value of the architecture skillset has been continuously reconfigured and applied to more business critical domains.

While ‘system architecture’ originally might have referred to the physical systems present in microchips and motherboard design, the architecture skill set was then quickly applied to software domains.  From there it further expanded and segmented into integration architectures, platform architectures, and application architectures.  The term system architecture was then co-opted to include multiple software components, expanded again to integrate the software components and the hardware components following the logic that they make up the entire system.

This expansion and segmentation continued.  The software and hardware architectures were combined to become the ‘solution architecture’.  But the ‘solution’ wasn’t just hardware and software so the term ‘solution architecture’ was refined again to encompass the context of what was now the technical solution as well as the business process change, financial modelling, and partnerships that supported the solution.

This continuous expansion and segmentation is as complex a history of a profession as you can imagine and it’s been played out over a relatively short period of time.  The debate on the exact definitions of various types of architectures will likely continue.  But right at the top is the elusive “business architect”.

But what, if anything, is a business architect? Unfortunately, this leaves the most important level of analysis and specialisation of the architecture discipline sitting precariously on top of a towering bundle of seemingly never-ending debates about architecture artefact, views, meta-models, and architecture governance.

Does the whole approach used by I.T. fall apart if this concept of a business architecture created by business architects doesn’t exist?

The Battle (with apologies to Christopher Alexander)

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 Manage Without Them 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 I.T. 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.

What’s this all got to do with information management? Well, information management is at the intersection of business architecture, general management, and I.T. So basically, you’re in for a bumpy ride.

Part of The Beginning and The End of Information Management.

Point to the data people 

I often did a bit of a pantomime early in my information management engagements with clients. You get yourself in a room with people from sales, marketing, information technology (I.T.), customer service centres, engineering, operations, field services – all over the organisation, at any level of seniority you please.

I’d let the conversation roll around a little and people would share their own reasons for why they were there and what problems they were trying to fix. Then I would ask “So, who is responsible for the information? Who manages it?”.

Everybody in the room would point to the I.T. guy. Firstly, it really was usually a guy, so that’s not being sexist in any way. But they’d just as happily point to a woman and they’d just as happily point down the hall if the I.T. team hadn’t even been invited to the meeting so that they could “keep it business focused”.

Before I’d get a chance to say anything, and I knew I didn’t need to, the I.T. guy would shake his head and reluctantly smile. He’d look sheepish but also a little smug. He’d look the way I.T. folks look a lot because they are often really smart, and often really driven to learn about their work, and know a lot of stuff about how your business works from the perspective they have managing your I.T. systems.

For all of this knowledge your I.T. folks have, they certainly aren’t in any way responsible for your organisation’s information! But before we even get to that there is already a problem we have to address. Why didn’t we ask this question earlier and how long have we been operating with this assumption?

If everybody in every department really does think the I.T. department, if not literally that one guy they invited to the meeting, is responsible for managing their information then we need to assume they haven’t been taking a systematic approach to managing it themselves.

If the I.T. department has in fact been the only group reluctantly taking a systematic approach to managing that information they need to get both credit for the successes they’ve had as well as the criticism for the failures that are likely already attributed to them.

More importantly, if the I.T. department is responsible for managing your information what happens when their initiatives to address information management challenges aren’t funded? What happens when a senior executive from marketing prints out a list of customer’s addresses and medical conditions and accidentally leaves in on the bus?

The idea that your “information technology” department is responsible for your information is wrong. I personally have a view that you could easily make them responsible for your information. But that takes effort and must of course be supported by increased authority. But today, in the average I.T. department the assumption is that “the business” is responsible for the information. The I.T. department controls “the pipes” but what flows through them is somebody else’s problem.

There are two reinforcing assumptions, they are equally perverse, and both must be challenged. Business units who think that being responsible for information is somehow beneath them and a job for “technical people” are making a miscalculation about the economics of information. I.T. departments who think there is a single, integrated, concept called “the business” that you can defer responsibilities to are either playing a game or burying their heads in the sand.

A quick overview of the first 30-40 years of the information technology revolution will help us understand how we got here.

Part of The Beginning and The End of Information Management.

Introduction

“The Beginning and The End of Information Management”

Information management is big news at the moment.  Put simply, information management is the strategic management of information to ensure it is captured, maintained, and used as required by your organisation’s strategic intent.  

If you’ve already been put off by the fact I used “information” and “management” in my definition of “information management”, or that I used “strategic” twice, you’re probably not going to enjoy running an information management initiative. 

I can’t think of any reason why you’d want to read this book if you aren’t trying to lead an information management initiative.  It’s not a general audience book.  But it does try to both introduce you to the concepts of information management while at the same time looking at the subject in a slightly different way.  

This book hopes to arm you with some ideas that will help you lead your initiative.  But if you’ve never been involved in an information management initiative before you might not notice when I’m trying to help you.  I’ll try, but you might still end up taking your initiative down a wrong turn and wasting hundreds of thousands of dollars.  But now you can blame me. 

The good news is these initiatives tend to take a long time, particularly when managed poorly, so by the time you’ve finished you might understand where I’m coming from.  You’ll be ready for next time at least.  At that point, just try not to come across as a know-it-all, like I fear I am now. 

There are at least three ways I view us being at both “the beginning” and “the end” of information management and therefore why I’ve included this in the title of this book.  

Firstly, I think the fact that we need information management initiatives is an anomaly.  It’s bizarre when you think about it. We all know what information is, and we use it every day. So why a special program to manage it?  Why haven’t we been naturally incorporating what we know about the economics of information into our change programs and improvement initiatives?

I think I know what happened, some of which I discuss in this book.  In brief, the discipline of general management, which was largely about telling people what to do, suddenly stopped working when information technology started being incorporated into the design of our organisations.  

While we noticed the big impacts of information technology, we didn’t notice other subtle shifts. So while general management stopped working immediately, the impact on our organisations took decades.  This 30-Year-Drift caused us to confuse “details” in general with “technical details”.  There are a lot of details to consider during an information management initiative, but they aren’t all “technical”. 

Conflating these concepts caused a drift of responsibilities into I.T.  departments that they never fully embraced. Even when I.T. departments tried to embrace these new responsibilities, other trends such as outsourcing accidentally eliminated the associated capabilities as not core to I.T.  

When we are starting an information management initiative, at “the beginning” so to speak, we must first address this drift.  

But we’re also at “the end” of this problem.  Indeed, if you are only just starting your information management initiative now you’ve already started too late.  It’s likely that your competitors are way ahead of you by this point.  This is “the end” in terms of being able to obtain any competative advantage by merely addressing this drift.  

Like all late starters, and smart second-movers, you also have an opportunity to learn from both the failures and the successes of others.  Where this book takes a different approach it is to try and help you leap-frog those who have come before you. 

Our second “beginning and end” refers to the way we think of information management frameworks.  At the beginning of your information management initiative you will adopt an information management framework.  This book includes the barest bones of such a framework (though I’d claim it is sufficient to get you started if you have nothing else).  

But in my view of how to implement an information management framework you have to think of this initial framework as something very different to the framework you will eventually build.  You need to use this generic, starting point, information management framework at “the beginning” to build your actual information management framework.  

This isn’t just a matter of customising, or picking-and-chosing elements of the framework; and this is why the initial framework doesn’t have to be particularly comprehensive.  Instead it’s about using the initial framework to generate a framework specific to the needs of your organisation.  

Notice I said “the needs of your organisation”, not “the needs of your stakeholders” or “business requirements”. I’m talking about things that are fundamental to how you operate as a business. These need to be discovered, not pushed to somebody else to define so we can tick them off a list. 

Under this approach there is a very real difference between the framework at “the beginning” and the framework at “the end”.

Thirdly, and this is personal, I’ve spent about half of my career involved in information management.  Sometimes this has been in the context of technology roles, sometimes as part of major programs and business transformations, and of course I’ve lead many information management initiatives.  

To me, I see information management as in my past.  I’m at the end of understanding our organisations as the sum of their information life-cycles.  This book represents my aging views of what I expect from the information management initiatives I encounter rather than what I’d like to actually be doing.  

But with every end comes a new beginning.  So for me this is the beginning of helping others get their information management initiatives right, and a time to look from the outside in as a consumer and stakeholder of information management initiatives as I enjoy the next phase of my career.