Archive for October, 2012
Imagine an electronics company planning a new tablet or phone and building the business case based on pre-committed orders. Similarly, imagine a utility trying to get residents to sign-up to their electricity plan ahead of the advertising campaign. It just wouldn’t happen. And yet, this is the model that information technology finds itself obliged to adhere to inside many large organisations.
How often do we hear of how an organisation needs an enterprise data warehouse and the first step is a departmental project? Similarly many a business is crying out for identity management, middleware and customer relationship management solutions that span divisions and other organisational siloes. Despite the chorus of agreement on the need, taking the first steps and then following through on the journey to implementing these foundational capabilities often seems too hard.
Technology projects are inherently complex but the last twenty years has seen the disciplines around the project management of information technology mature. Regardless of whether the approach is waterfall or agile, the objective of formalising the implementation is to reduce the rate at which information technology projects fail. The proponents of waterfall require thorough specification of requirements ahead of development with clear stakeholders. The advocates of iterative or agile methods require the organisation to stand-up fewer capabilities at one time through the engagement of a smaller group of stakeholders who are actively involved.
Increasingly, as a result of this maturing, our profession can be proud of our success rate at delivering solutions for individual departments or divisions. However, when the solution provides a service that spans the enterprise, problems and general dissatisfaction still seem to be more common than not.
Part of the problem is the very focus on individual projects that has helped to so dramatically improve the success rate of information technology investments over the past couple of decades. Like the utility company launching a new electricity or gas plan, enterprise solutions are typically providing a service that will be used in a myriad of different ways by their stakeholders. Rather than intricately collect the requirements of these individual users, the best that the information technology team can do is to define a service with specific parameters and test them with focus groups.
The situation is even more complex when the funding of these enterprise solutions is considered. Even businesses that reject cost recovery from individual stakeholders struggle to kick these projects off or sustain them past the first tranche of functionality.
When treated as a series of individual projects, someone has to go first. For a data warehouse that might be marketing, finance, or an individual line-of-business. Similarly for customer relationship management, one product area might have the most obvious and compelling need. Individual needs can always be delivered more effectively as standalone solutions without establishing capability for the future. Even the most enlightened team, supported by the most visionary executives, find it hard when focused on delivering a project to avoid compromising the future for the sake of dealing with the complexity of the present.
Worse, when progressing to the second and third drops the focus and urgency is often lost as the initial surge of enthusiasm supported by the most pressing business need begins to dissipate.
There is, however, a solution. Increasingly business and government is moving beyond a model that only supports new functionality as a series of projects and is shifting the focus to capabilities and services. The concept of a service enables the business to look at the return on investment in the same way as consumer focused businesses, like an electronics company, look at the potential of a new product launch.
As the tools of service management mature, and there is a convergence of thinking on the funding and resourcing of technology delivery, far more complex capabilities are becoming easier to develop with fewer missteps. In this environment technologists don’t need to apologise for the complexity of the foundational technologies that the organisation needs rather they can make them available and support their evolution without requiring any one group take that first big leap of faith.
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?
We’ve just released the fifth episode of our Open MIKE Podcast series!
Episode 05 features key aspects of the following MIKE2.0 solution offerings :
Big Data Definition: openmethodology.org/wiki/Big_Data_Definition
Big Sensor Data: openmethodology.org/wiki/Big_sensor_data
Hadoop and the Enterprise Debates: openmethodology.org/wiki/Hadoop_and_the_Enterprise_Debates
Preparing for NoSQL: openmethodology.org/wiki/Preparing_for_NoSQL
Big Data Solution Offering: openmethodology.org/wiki/Big_Data_Solution_Offering
Check it out:
Open MIKE Podcast – Episode 05 from Jim Harris on Vimeo.
Want to get involved? Step up to the “MIKE”
We kindly invite any existing MIKE contributors to contact us if they’d like to contribute any audio or video segments for future episodes.
On Twitter? Contribute and follow the discussion via the #MIKEPodcast hashtag.
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?
Last week, I discussed sloth. I examined the inherent tendency of some people to postpone working–often to the detriment of the organization. This week, I’ll cover lust defined by Wikipedia as:
an emotion or feeling of intense desire in the body. The lust can take any form such as the lust for knowledge, the lust for sex or the lust for power. It can take such mundane forms as the lust for food as distinct from the need for food. Lust is a powerful psychological force producing intense wanting for an object, or circumstance fulfilling the emotion.
Alright, but what does that have to do with IM projects? Moreover, is lust inherently bad?
Lust and IM
Many organizations want to do more than they are currently doing–and, just as important, are currently capable of doing. Think about the new CIO or CEO who comes in to an organization, astonished to see that it isn’t doing anything with respect to Big Data, semantic technologies, business intelligence, or other “Enterprise 2.0″ things. Or perhaps that new CXO finally wants the organization to embrace a more data-oriented mind-set.
New leaders want to put their stamps on their organizations. After all, they were recruited because they had a specific vision of where to take the company. If promoted from within the organization, the same principle applies. Succession plans exist for a reason, and few people are supposed to just maintain the status quo. (Yes, this even applies to Tim Cook.)
Is lust inherently bad?
I’d argue no. In an IM context, lust is a fundamentally function of wanting to do something better, whether it’s selling more widgets, increasing profits, doing more with technology, and the like. So, what’s the problem with lust? Isn’t it tantamount to self-improvement?
In short, lust can get leaders, departments, and organizations in trouble when it involves reaching way beyond the capabilities of the enterprise, individual personnel, and/or departments. For instance, it’s sure easy to envy Apple, Facebook, and Google. However, there might be a very good reason (or ten) that a mature organization cannot interpret data as well as those companies.
When listening to the oft-compelling pitches from enterprise software vendors and consulting firms, one starts to dream, “What if we could do exactly what Google does? Wouldn’t that be great?”
Yes, it would, but here’s the rub: Your organization isn’t Google. Specifically, Google doesn’t struggle with basic data management. Its employees don’t cling to antiquated ways of doing things. The company doesn’t rely upon a cauldron of legacy systems to run its enterprise. Google employees don’t have to manually cobble together user statistics over a period of months. Google doesn’t struggle to provide real-time statistics to advertisers, users, and partners.
If your organization does these things, then it’s unlikely that it will be able to reap the benefits of Google-type technologies.
Use lust sparingly. Yes, it can serve as motivation to get better, but don’t let it cloud your judgment. Realize the limitations of your organization. Take steps now to improve data management, organizational culture and agility, and the like now. Only then can you satisfy your lustful IM desires.
What say you?
Next week: pride.
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.
TODAY: Fri, April 28, 2017October2012