Archive for the ‘Information Management’ Category
Many of us walk around with the knowledge that we generally understand how the world works. When people ask us for our professional opinions, we’re often more than happy to oblige. Some of us are even flattered when someone wants to know what we should do when faced with uncertainty.
But do we know as much as we think we do? I have my doubts, especially after finishing Everything Is Obvious: How Common Sense Fails Us by Duncan J. Watts. It’s a thought-provoking book because it challenges readers to ask themselves, “What do we really know?” The answer, unfortunately, is not as much as we think.
Simple vs. Complex Systems
As Watts points out, part of the problem stems from the distinction between simple and complex systems. Let’s take a simple situation: the game of blackjack. I’ve been known to play a few hands, and only a fool would hit on 18 with the dealer showing a six. It’s just bad strategy. In such a simple environment, the best decision is clear.
The problem with simple systems is that they aren’t terribly representative. In complex systems like, say, the economy, myriad forces are at play, the vast majority of which are not under the control of any one person, group, department, or organization. Even the US government could not completely solve the financial crisis with a $900 billion stimulus. Bottom line: there’s only so much that any of us can do in a complex system.
And, as I turned the final pages on what is easily the best book I’ve read this year, I started to think about that big question in the context of Big Data. If we truly embrace Big Data, then we will have to question many long-held assumptions about how many things work: our jobs, our departments, our industries, and our environments. Looking at data with open eyes means that we may not like what we see, nor what that data will tell us. And that makes many of us uncomfortable. How many of us want to constantly question what we think we know?
To me, Big Data is not all about technology. Far from it. I’d argue that there’s a human element in all new technologies, and Big Data is no exception to this rule. There’s an organizational readiness component to it, as well as a personal one. Will people and organizations unaccustomed to consulting the data suddenly change their behavior? Will they be open-minded? Or will they act as if they know how things have worked, work now, and will work in the future.
It’s a big question. Big Data may prove that you don’t know as much as we think you do. What will you do then?
What say you?
I recently had some palm trees put into my backyard in my Nevada home. It was a downright cool experience that required industrial cranes to life the two-ton trees above my home.
There was no damage done to my home or the driveway and nobody was injured. Everything went well. Well, almost everything. It turns out that the truck carrying these trees was delayed.
Did the drivers have hard time loading these monstrosities? No. Was the enormous truck able to snake its way into my community? Yes. So, what was the problem?
Good old human error. When I bought the trees, my friend Jeff accompanied me. Jeff knows a thing or two about landscaping and I’m anything but a palm tree expert. I paid for the trees and gave the woman at the counter my proper address. I assumed that all was good to go.
Fast forward to tree delivery day. After a few hurried calls and general wonderment about where these things were, we identified the culprit. The saleswoman wrote down Jeff’s address on the deliver-to line, not mine. She put my address in the ‘notes’ section. For their part, the delivery guys didn’t read the notes and wound up driving 60 miles out of the way.
I’ve seen many parallels between palm trees and enterprise data in my career. I’ve had users question the accuracy of my reports. I might hear things like “There’s no way that we had that many promotions last month! You’re report is wrong!”
While I’m not perfect, I would often tell the skeptical user that we should check the data in the source system. More often than not, my report was accurate but the data pulled into that report was not. Thanks to audit tables and metadata, I could typically pinpoint the time, date, and creator of the errant record.
I would then work backwards. That is, after we knew that a user made this mistake, I would ask the natural next questions:
- What other mistakes did this user make?
- What else do we have to clean up?
- Is there a larger departmental or organizational training issue?
- Couldn’t we write a business rule or audit report to prevent the recurrence of this problem?
Everyone makes mistakes, and I’m certainly no exception. The larger point here is that data matters, especially the accurate kind. One of my favorite expressions is PICNIC–aka, problem in chair, not in computer. We can do simply amazing things with Big Data, but I’ll always insist that Small Data and data quality are just as important.
What say you?
With the rise of Apple’s iCloud and file-sharing solutions such as Dropbox and Sharepoint, it’s no surprise that SaaS and cloud computing solutions are increasing in popularity. From reduced costs in hosting and infrastructure to increased mobility, backups and accessibility, the benefits are profound. Need proof? A recent study by IDC estimates that spending on public IT cloud services will expand at a compound annual growth rate of 27.6%, from $21.5 billion in 2010 to $72.9 billion in 2015.
While the popularity and acceptance of cloud computing has certainly taken off, new questions are being asked regarding the security of third-party data hosting. Has the centralization of IT into a few cloud computing platforms made it easier for the “bad guys” to focus their efforts? With valuable information from all departments ranging from marketing to accounting being openly shared with another organization, are your customer preferences, past orders, mailing lists, HR and financials at an increased risk for cyber threat?
Despite this concern, an alarming study by the Ponemon Institute, which surveyed over 900 IT executives across the world, found that about half of worldwide IT organizations said that no one in their organization evaluates cloud computing providers for security. Worse yet, another half said they were pretty sure that no one in their organizations knew about every cloud computing service that end users in their company were storing data on.
Can you really rely on the cloud to keep your enterprise information safe? What information are you sharing and what steps has your organization taken to evaluate providers for security?
In part four of this series, I discussed lust from an IM standpoint. Now it’s time for pride, defined as
an inwardly directed emotion that carries two common meanings. With a negative connotation, pride refers to an inflated sense of one’s personal status or accomplishments, often used synonymously with hubris. With a positive connotation, pride refers to a satisfied sense of attachment toward one’s own or another’s choices and actions, or toward a whole group of people, and is a product of praise, independent self-reflection, or a fulfilled feeling of belonging.
Let’s apply the concept of pride to this blog.
The Downside of Pride
All too often in the corporate and IM worlds, pride rears its ugly head into things–often with disastrous results. For instance, at one organization at which I worked, a senior IT director and 20-year-veteran (Al) was quite proud of the systems and he and his team had built. “His” systems handled the organization’s payment of employee bonuses and the distribution of stock options.
To be sure, this wasn’t “rocket surgery”, but doing this across more than 60 countries wasn’t as easy as it might sound. Al was so proud of his systems that he fought efforts to deploy an enterprise-wide solution for years, erroneously telling his colleagues that COTS applications couldn’t do what his programs could.
For years, Al was able to postpone the organization’s implementation of PeopleSoft. When he couldn’t delay it any longer, Al fought successfully to have the ERP highly
bastardized customized to “integrate”–and I use that term very loosely–with his systems. The end result: an absolute mess of data coupled with a spaghetti architecture. (For how architecture ought to be, click here.)
A Different Example
Of course, pride need not hamper organizations. Contrast Al with a manager I met while consulting at a VOIP company. Steve was in fact proud of the customer applications that he had built. Without question, they had served a purpose as his company more than tripled in size. As business continued to grow, it was becoming more and more apparent that, on many levels, his creations were reaching their limits. I was nervous speaking with him: I knew that I needed to have a difficult conversation with him.
To his credit, Steve didn’t let pride get in his way. Steve knew that those applications could only do so much. In his own words, he knew that he’d at one point soon need to throw the baby out with the bath water. Whether he built new systems or implemented existing ones in the future, Steve knew that his company would be better off than it was now.
So, what separated Steve and Al? After all, both were proud of what they had accomplished. First, Steve was much younger than Al. Oftentimes people near the end of their careers are concerned about their legacies; they want to leave their mark on their organizations. Beyond age, though, there’s something in the DNA of people. Some folks can be simultaneously proud of what they’ve done–and still realize the limitations of their accomplishments.
What say you?
In today’s data-driven society, it’s not uncommon for businesses to rely on multiple information systems to complete their day-to-day operations. As the Marketing Director for a small consulting firm, I can think of at least five that our department uses regularly to perform basic tasks:
- Customer Relationship Management System (CRM)
- Content Management System (CMS)
- Email Marketing Platform
- Fileshare System
- FTP/Web server
Each of these systems (or subsystems, if you will) play a role in comprising our overall Marketing Information System, yet each has its own user interface with unique data fields and import/export options. Because I’ve been with the company for years, I am versed in the “what goes where” of adding and manipulating data. A new-hire, however, would not be. And as our company continues to expand, we’re faced with how best to communicate how this “system of systems” works and what data needs to go where so that reports run correctly.
In your experience, what should be done to make it more clear to end-users “what information goes where” across overlapping information systems? How can we avoid end user entry errors and ease the learning curve for new hires and temporary staff?
In my last post, I talked about greed as it relates to IM projects. Long story short, for different reasons, people actively refuse to share information, train employees, or generally cooperate with others.
Today’s topic: sloth, defined by Wikipedia as:
…spiritual or emotional apathy, neglecting what God has spoken, and being physically and emotionally inactive. Sloth or lut can also indicate a wasting due to lack of use, concerning a person, place, thing, skill, or intangible ideal that would require maintenance, refinement, or support to continue to exist.
To be sure, on information management (IM) projects, the ultimate effects of sloth often resemble those of greed–i.e., work just doesn’t get done in a timely manner, if at all. Alternatively, work is just sloppy. However, the motivations behind sloth and greed are typically quite different.
Greed inheres a certain defiance and even anger. For instance, consider Barry, an employee who isn’t happy that his job is changing. No one asked him what he thought. Maybe he has to learn a new skill or application. Either passively or actively, Barry expresses this anger in the workplace. Take away the change in Barry’s job and he would not have been problematic.
By way of contrast, sloth lacks the same type of precursor. When sloth manifests itself, an employee doesn’t necessarily feel aggrieved. Nothing is changing with Lillian’s job and she’s actually pretty happy. Maybe her boss asked her to look into Big Data. However, for whatever reason, she just doesn’t feel like it. She’d rather play Angry Birds while no one is looking.
Now, sloth should not be mistaken for an employee with conflicting and diverging priorities. For instance, on my ERP projects in my career, I would need to meet with the Director of Finance or the Payroll Manager for different reasons. The organization was deploying a new CRM or ERP system and my job involved activating that new system. (Of course, I couldn’t do it alone.) Unfortunately, I would often have trouble scheduling time with individual clients because they often had to deal with emergencies. By definition, these issues trumped any “future plans” that I had to discuss with them. Consequently, my meetings were sometimes canceled.
This isn’t sloth; this is just reality. A problem with testing or training in a new system always loses to an immediate organizational crisis. Consultants need to get used to this. It’s an occupational hazard.
Sloth is often a function of knowledge, curiosity, and personality. Consider the following problem: similar but not identical customer or employee data from two different spreadsheets has to be married–say, 2,000 records.
Sure, there are people who believe that this has to be a manual exercise. Because of this, they just don’t feel like doing this type of monotonous work. But plenty of people are naturally curious; they know that there just has to be a better way to do this. Adventurous and inquisitive folks are rarely lazy. They either know about Excel’s VLOOKUP function. Alternatively, they will search the web or ask others if there’s a better way to marry data. JOIN statements come to mind.
Understanding sloth is the first step in preventing or minimizing it. Ignore it at your own peril.
What say you?
Next up: Pride
In my last post, I discussed the impact of wrath on IM projects. Today’s topic is the second of the deadly sins: greed.
Note that greed and sloth (to be discussed in a future post) are very different sins.
Now, let’s start off by getting our terms straight. By greed, I’m talking about the need for certain employees, groups, and departments to hoard data that ought to be shared throughout the organization. These folks are keeping for themselves what others want and/or need. For instance, consider Steve, a mid-level employee at XYZ who keeps key sales or customer data in a spreadsheet or a standalone database.
Or consider ABC a company that implemented a new system that, for different reasons, was never populated with legacy data. Barbara in Payroll holds key payroll information and will not willingly provide it to Mark in Accounting.
To be sure, organizational greed is hardly confined to data. I’ve seen many employees over the years refuse to train other employees or lift a finger to help a new hire or perceived enemy. Maybe they refuse to meet with consultants hired by senior management to re-engineer a process.
Understanding the Nature of Greed
I could go on with examples but you get my drift. Almost always, greed emanates from some fundamental insecurity within the offending employee. What’s more, at the risk of getting myself in a whole heap of trouble, I’ve found that more senior employees are more likely to be greedy. Now, this is a broad generalization and certainly does not apply across the board. I’ve seen exceptions to this general rule: young employees who wouldn’t share information and near-retirement-aged folks more than happy to show others what they know.
As employees become less secure about their jobs and themselves, they naturally start to think about the future–their futures. It’s just human nature. Many people understandably don’t want to be looking for jobs today. (This feeling increases as we age, what with many familial and personal responsibilities.) We realize that the grass is not always greener. For some of us, this manifests itself in a tendency to attempt to protect our jobs, departments, budgets, fiefdoms, and headcounts–at least until the perceived threat diminishes.
But there’s a critical and countervailing force at play for the greedy: Information wants to be free. As open-source software, open APIs, and open data sources continue to sprout, people are becoming less and less tolerant of employee bottlenecks. Those who refuse to play ball may be able to temporarily stall large-scale information management projects, but eventually, by hook or by crook, those damns always break.
I wish that I had a simple solution for resolving employee-related greed issues. I don’t. Many tomes have been written about managing difficult employees. At a high level, organizations can use two well-worn tools: the carrot and the stick. Consider rewarding employees who share information and knowledge while concurrently punishing those who don’t.
What say you?
Next up: sloth.
Most of us have heard of the seven deadly sins: wrath, greed, sloth, pride, lust, envy, and gluttony. Inspired by Simon Laham’s book The Science of Sin, I’m kicking off a seven-part series in which I look at these sins in the context of information management (IM).
Today’s installment: wrath. Think of wrath not as the final sin in the chilling movie Se7en, but as the equivalent of anger. As any psychologist can tell you, anger manifests itself in one of two forms: passive and aggressive.
Let’s cover each from an IM perspective.
In order for just about any large-scale IM project to have a remote chance of being successful, people need to work together. To be sure, collaboration is essential (although I’d argue that it’s a necessary but insufficient condition for success). Yet, for whatever reason, often individuals have axes to grind and won’t work with consultants, vendors, colleagues, and even senior leadership. Rather than outwardly defying others, these folks vacillate. They make excuses. They ensure that other, more important (at least, in their view) priorities take precedence. Or perhaps they’ll do nothing. They’ll ignore an email or not return a phone call.
Without question, this is the more common of the two forms of anger. Now, let’s move to the counterpart of passive anger.
Aggressiveness and outright defiance are much, much less common on IM projects. Rarely will an employee be so recalcitrant that he will flat-out refuse to do something, raise his voice, or physically threaten another person. The reasons are obvious. While employment laws vary considerably by country, in many parts of the world you have no right to a job. For instance, in the United States, at-will employment is the norm with two important exceptions:
- employment contracts with clauses outlawing certain types of behavior
- certain unionized environments (both public and private sectors)
Translation: those that behave in a manner not conducive to workplace tranquility can be terminated.
Yes, intraorganizational aggression tends not to take place very often. That’s not to say, however, that interorganizational aggression rarely happens. On the contrary, many organizations have lamentably bad relationships with some of their suppliers, customers, vendors, and other third parties. Many times, the very of source of this conflict is (you guessed it) data.
For instance, organizations implementing new systems often need to receive special attention from insurance and financial institutions as they test new interfaces. Fair enough, right? The problem: those third parties often have to service thousands of other equally important clients, making it nearly impossible to devote exclusive resources to the organization replacing its legacy systems. The end result is often yelling and screaming.
I’d argue that aggressive anger is actually better for IM projects for one simple reason: you know where the aggrieved party actually stands. With passive anger, you have to guess if John or Jane is really overburdened with other work or is just angry about the tasks asked of him/her.
What say you?
Over the last few months I’ve had the opportunity to collaborate with a range of my Deloitte colleagues on a report into the “digital disruption” of business. The result brings together the impacts of digital technologies, with the explosion of information and the enabling capabilities of cloud. For me, the most important aspect of the collaboration has been the separation of digital from its purely technical connotations. While focused on Australia, the report’s findings are largely applicable to all geographies.
Hear the word “digital” and your mind races to the latest internet or mobile device. Over the past forty years many new technologies have been introduced which have caused disruption and met this definition of digital.
Some examples include the wide introduction from the 1970s of the “digital computer” a term which no longer needs the digital preface. Similarly the digital mobile phone replaced its analogue equivalent in the 1990s introducing security and a raft of new features including SMS – who recalls the number of scandals caused when radio hams listened into analogue calls made by politicians? Digital communications over the internet are simply another example of various analogue predecessors being digitised.
Digital business separates its constituent parts to create independent data and processes which can then be assembled rapidly in a huge number of new and innovative ways. Airlines are a good example. Not that many years ago, the process of ticketing through to boarding a flight was analogue meaning that each step led to the next and could not be separated. Today purchasing, ticketing and boarding a flight are completely independent and can each use completely different processes and digital technology without impacting each other. Passenger handling for airlines is now a digital business.
What this means is that third parties or competing internal systems can work on an isolated part of the business and find new ways of adding value. For retailers this means that the pictures and information supporting products are independent of the website that presents them and certainly the payment processes that facilitate customer transactions. A digital retailer has little trouble sharing information with new logistics, payment and mobile providers to quickly develop more efficient or new routes to market.
If you don’t think that this is going to impact you in the short-term, then the report’s analysis should convince you otherwise. 32% of the Australian economy (and by extrapolation the economies of other countries) will experience a major disruption in 0 to 3 years and a further 33% will be similarly impacted in 3 to 5 years. Impact is one thing, but this report leaves you with a sense of just how much work there is still to be done to respond to the digital challenge.
Up until four years ago, I made all of my money on large-scale IT projects. Many of these informed my first book, Why New Systems Fail. Since that time, I gradually made the break into speaking, writing, publishing, and website design.
As a result, my P&L statement looks nothing like it did back in 2008. Yet, in a way, absolutely nothing has changed. For years, this dude has abided by the 70-30 rule. That is, whether it’s a multi-million dollar enterprise system or open-source software like WordPress, I consider myself 70 percent functional. Note that the 70 percent rule applies to both Waterfall and Agile projects.
This means that I learn about the front-end a software application works because that’s where most users spend their time. It doesn’t matter if you’re paying vendors or employees, entering sales, or writing blog posts. Most people spend the vast majority of their hours in an application as functional users, not technical ones.
The Importance of the Other 30 Percent
Yet, at least for me, the other 30 percent is key. At times, functional users will have technical questions about how an application works, where its data is stored, how to change or customize something, and the like. The purely functional consultant or web designer can only get you so far. I’ve never met anyone completely satisfied with a vanilla application after using it for any substantial length of time.
I can tell you that forcing myself to be 30 percent technical has actually increased the depth of my “other” 70 percent. In other words, if you understand a good bit of the technical side, then you will augment your appreciation and knowledge in the functional side.
And I’m hardly the only one who feels this way. I asked my friend, entrepreneur and WordPress designer Todd Hamilton about this.
There are quite a few steps in knowledge from simple end user to developer. To do either job really well, a person needs an overall knowledge framework of the system on which she is working with from both perspectives. For the WordPress simple end user, this requires understanding several things: 1) a bit about what a database is; 2) that the WordPress admin is for putting stuff in the database; 3) that the WordPress theme displays that data.
For the WordPress developer, that means understanding: 1) how users intend to interact with the data; 2) what makes sense to them; 3) what is too complex. A good dynamic is where both the developer and the end user share that knowledge framework and then the focus becomes execution instead of achieving understanding.
Hamilton’s exactly right here and his WordPress lessons can be extrapolated to other applications.
Simon Says:Find the Hybrids
When hiring a consultant for any type of technology project, ideally check his or her technical credentials. A purely functional consultant probably isn’t up to speed on the application’s data model–something that might have enormous implications down the road.
Ditto on the technical end. Someone without a lick of functional or application knowledge isn’t going to appreciate the legitimate challenges of most of the audience for that very application.
What say you?
TODAY: Fri, July 11, 2014July2014