In last week’s post, I wrote about organizations that fail to secure the requisite resources while undertaking major information management (IM) initiatives. In today’s post, I’ll extend the discussion to another source of resource-based problems on these projects: money.

Penny-Wise, Pound Foolish

When it comes finding the right resource for an IM initiative, many organizations are cautious with small amounts of money but careless with larger amounts. While attempting to procure independent contractors or full-time consultants/vendors, many focus exclusively on hourly rates. (This is particularly true if third parties such as recruiters or consulting firms are involved. These companies often attempt to pressure the consultant or subcontractor into taking the lowest possible rates.)

Focusing on hourly rates alone is one of the cardinal sins made by organizations during IM and IT initiatives. Such myopia misses the big picture and ignores the very important concept of Total Cost of Ownership (TCO).

Now, this is hardly rocket science. A consultant or subcontractor with superior skills might–and probably does–charge a premium rate. However, highly skilled individuals can often accomplish their work in far fewer hours than their lesser-skilled counterparts.

An Example

Consider the following fictitious example. Griffin, Inc. is a major manufacturer of toys. Over the years, the company’s data and systems have become increasingly segregated. Orders are often incorrect, delayed, or shipped to the wrong location due to inaccurate customer information in its cauldron of systems. Management is starting to realize that this problem isn’t going away; it’s getting worse.

Griffin has decided that enough is enough. It will begin a major IM project with the ultimate intent of consolidating and purifying its data. For this, it needs help. The hiring manager, Peter, has the resumes of two candidates:

• Brian charges $125/hour for his services. He has extensive programming, data analysis, and general business experience. He can interpret requirements that are anything but iron-clad.
• Stewie charges $90/hr his services. While no newbie, he just doesn’t bring the same skills to the table as Brian.

Pressed for money, Peter tries to get Brian to come down to Stewie’s rate. Brian has some flexibility but ultimately won’t come close to $90/hr. Peter goes with Stewie, thinking that he’s ultimately saving money.

But is he?

Stewie is no fool, but he’s simply not in Brian’s class. He struggles trying to make logical inferences. He doesn’t have the same tools in his bag as Brian. Stewie is unaware of existing frameworks that mitigate project risk and allow for smoother transitions, such as MIKE20.

Against this backdrop, it ultimately takes Stewie about six months to complete the project. He bills Griffin for 1,000 hours of his time. Brian could have performed the work in half that time. Consider the following TCOs of each:

• Brian’s TCO is $62,500 (500 hours * $125/hr)
• Stewie’s TCO is $90,000 (1,00 hours * $90/hr)

Also consider potential travel expenses and the fact that Stewie needed to engage Griffin employees for three extra months, taking them away from their day jobs. Also, what about the issues that Brian would have found?

Simon Says

Look, money matters in any economy, much less this one. There’s always a temptation for organizations to make do with “adequate” resources. Sometimes paying more on an hourly basis results in a lower TCO; highly-skilled resources often more than justify their  premiums. Don’t dismiss resources simply because they initially appear to be too expensive in the near-term. Ask yourself if actually they’re cheaper in the long-term.

These days, I’m pretty immersed in the world of small companies for one reason: I have been interviewing the owners of small businesses for my new book. Quite frankly, I have been blown away by many things, not the least is which the ability of these companies to effectively manage their data. In this post, I’ll explore the small and big worlds of information management )IM).

The World of Big

I have spent many years in this world, so I feel like an expert commenting on it. If you’re reading this post, then you’re probably familiar with it and its characteristics:

• Big Companies
• Oodles of employees
• Politics galore
• Big Tools (typically older)
• Big Data (often inconsistent, incomplete, or at at least partially invalid)
• Big Systems (note: always plural)
• Big Problems

In what appears to be Bizarro World, I have spent much time lately in The World of Small. Even the project that I am finishing next week involves a company with “only” an 800 employees. At least to me, this is relatively small. This is especially true since I’ve done time in organizations with more than 60,000 employees. (Well, at least we thought that that number was right.) Our systems were more than a little messy and we could never be sure. Calm blue oceans, Phil…

The World of Small

The characteristics of this other, strange wold include:

• Small Companies
• Fewer employees (by an order of magnitude)
• Smaller Tools (typically newer)
• Smaller Data
• Smaller Systems or, heaven forbid, system (singular)
• Smaller Problems

Worlds Colliding

Now what happens when those people used to one world enter the other? Worlds collide. (In “The Pool Guy”, one of my favorite Seinfeld episodes, we are introduced to George’s “Worlds Theory.” Long story short: friends and relationships don’t mix.)

When those used to working in small worlds enter big ones, they often become frustrated. The simple ability to query relatively accurate data sets gives way to much more nuanced (read: complicated) situations. Relatively simple questions are answered with complex or convoluted answers such as:

• “not really”
• “sometimes”
• “you’d think so, but…”
• “it depends”

I suspect that this is why many highly talented folks leave big companies for small ones, never wanting to return.

On the other hand, those that go from big worlds to small ones seem to feel a sense of immediate relief. They’re surprised with statements such as, “If it’s not in Salesforce.com, then it doesn’t exist.” How’s that for an IM philosophy? Or how about being able to write accurate reports via a web-based wizard that pull results in 30 seconds?

Yep. It’s a strange world.

Simon Says

Most companies lay somewhere in between these two poles. What’s more, to be fair, small companies have their own issues and it’s the acme of foolishness for me to claim that these environments are idyllic. To quote Stephen A. Smith, However….

On many levels, there’s something to be said for simple setups, consistent data, quick decision making, clear lines of responsibility, and generally better data. Even if The Big World can’t turn on a dime, shouldn’t its leaders try to emulate its smaller counterpart?

Feedback

What say you?

After submitting my final draft to Wiley at the end of last year, my wait is finally over!  I have just received one of the first copies of my new book, Information-Driven Business: How to Manage Data and Information for Maximum Advantage.  Mostly I try to write here on topics that affect our profession, but I hope you’ll forgive me for being a little self-indulgent in this short post.

For many years I have believed that the Information Revolution is real and that we are in the middle of a historic change in business.  I was privileged to work with a number of regular participants in this blog and the www.openmethodology.org site to establish MIKE2.0.  I continue to enjoy the opportunity to work in the field of Information Management.

Some time ago, I decided that the techniques that I have used for many years to prioritize business strategy, design business information solutions, and to measure the use and value of information needed to be consolidated in one place.  The result was a manuscript that I’m proud has now been released by Wiley under the title Information-Driven Business.  More details about the book have been compiled at www.infodrivenbusiness.com.

Some people have asked me why I went to the trouble of writing a book when we are able to publish so easily on the Internet.  The answer is that while it is easy to get material online almost instantly, a book has an authority and authenticity that reflects the effort required to get through the publishing process.

I hope my book is well received.  Perhaps more importantly, writing it has given me the chance to have my say.  Either way, I will watch the journalist reviews together with your comments on Amazon and other online bookstores with a great deal of anxiety and interest!

It’s an interesting question.

In Outliers, Malcolm Gladwell discusses the notion that one needs to have worked 10,000 hours at something to be considered an expert. For example, Bill Gates was an expert at computing by the early 1980s because he had spent so many hours in front of terminals learning how to use computers and how to program.

I’m reluctant to call myself an expert on many things. In fact, I often preface my comments with “I’m not an expert, but.” Evidently, I then have a tendency to say something particularly profound about the very topic on which I am no expert. (With age comes humility, I suppose.) Recent examples include cloud computing, open source software, or another topic. I’ve had a few people tell me over the last few months that I should stop saying that. Perhaps I am making them feel uncomfortable.

What can I say? I must have picked up a great deal of knowledge about emerging technologies from the contributors to my second book. I also read a great deal.

This makes me wonder:

• Does being an expert really matter?
• Does the myriad of information on the internet allow us to become experts more quickly, than say, twenty years ago? Or is it easier to fake your way through things by doing five minutes worth of research of Wikipedia?
• Is it better to understate your expertise in something than overstate it?

Varying Skills

As a consultant, I’ve worked with many people whose information management (IM) skills ran the gamut. A few people were every bit as good as they said they were, worth their weight in gold. (In fact, I recently finished a project with two such folks. Good to know if I wind up hiring additional resources in the future.) At the other end of the spectrum, some people talked a good game but, when push came to shove, they could not deliver the results, forcing others to pick up the slack.

Sadly, many of those who have routinely disappointed me were external–and highly paid–consultants whose firms chose not to send in those with the requisite expertise. While I’m probably pretty biased here, I have found that larger consulting outfits sometimes still staff projects with whoever is available or, in the parlance of the consulting world, “on the beach.” Somehow, availability trumps being qualified.

Simon Says: Determining Expertise

Unfortunately, there’s just no way to know for certain if you’re bringing in someone who can walk the talk–and this is coming from someone with pretty extensive knowledge of different interviewing techniques. Sure, you can ask behavioral-based questions to attempt to ascertain who’s faking it but even those guarantee nothing. Use them as a starting point, then solicit the opinions of other well-respected folks. At least for me, those are tough to ignore. Consider what they say as well as what they don’t say.

While I’m at it, here are a few more tips:

• Certifications are fine and dandy but give me the experienced resource who lacks a proper certification over the newly-minted and certified neophyte.
• Clients should structure contracts in such a way that they’re not stuck with a resource whose resume doesn’t match his skill set. Also, don’t be afraid to pull the plug on anyone (contractor, consultant, employee, or partner) who’s not delivering the goods.
• As for 10,000 hours, it’s a nice proxy but the fact remains: some people simply pick things up quicker than others. I’ve worked with folks who couldn’t get with the program after extensive training and others who could look at something and immediately essentially got it.

Feedback

What say you?

I recently had some customer service issues with a few telecommunication companies. When calling the 800 numbers and speaking with reps about my issues (and there were quite a few), one thing kept frustrating me: receiving different answers to my questions from different people from the same company.

In large part, this stemmed from the fact that different customer service reps at each company had access to different data. Oh, how I loved the lines “I don’t have access to that information” and “That’s not my department, sir.” I don’t attribute this to issues related to permissions, rights, or security. Rather, I strongly suspect that each department kept its data in different systems. Because these systems didn’t talk to each other (or receive real-time updates from each other via some type of ETL tool), each rep would tell me the “current” information in his/her own system.

Now, it’s easy for me—and people like me—to view the world exclusively through our normal lenses. In my case, I’m a technology guy. People like me know more than a little about information management (IM). We understand things that some people don’t. (Of course, we often don’t understand things that we probably should, but that’s a conversation over beers sometime.)

IM types understand all too well why many large organizations struggle keeping tabs on their data. The usual suspects are:

• An eye chart of disparate systems
• End user inattention to detail
• Organizational charts nowhere near transparent
• Bifurcation of responsibilities among different departments
• An inattention to data quality and data governance

John Q. Public

To most people reading this post (and similar posts on data- and management-oriented sites), this is old hat. But consider John Q. Public. He is no data management expert. He doesn’t know the difference between a house key and a primary key. He probably wouldn’t be able to define data quality or referential integrity.

But here’s the rub: It doesn’t matter.

John’s no idiot. He knows bad customer service when he experiences it. He may not know why a company is giving him the runaround, but he sure as heck doesn’t like it. What’s more, he now has new options for expressing his disgruntlement.

The social web has shifted the pendulum to the customer, empowering people in ways simply not possible even fifteen years ago. As Maria Ogneva writes, this “social customer” is not terribly tolerant of old school customer service practices. They don’t bite their tongue when things go awry. Ogneva writes:

With easy publishing tools, creating content is easy. With social sharing tools, it’s even easier to share this content with as many people as are in your network, and with platforms as good for discovery as Twitter is, you can even expose your message to anyone tracking that topic. So now, this same customer, who’s had opinions of her own about any and every product she’s ever used, can publish and share her thoughts with a mouse click. And if you are looking for information on that product, you can find what other people have already said.

Simon Says

Today customers have at their disposal many tools to communicate their happiness—or lack thereof. This has enormous implications for data management. Small businesses get a bit of a free pass here because they often know their customers via personal relationship. By contrast, few corporations can make that claim. When it comes to more effectively managing their data, large organizations need to get their acts together. The risk of not doing so: losing current and future customers.

Feedback

What do you think?

As I familiarize myself more and more with the MIKE2.0 framework, it’s obvious to me that it’s highly contingent upon collaboration. In general, collaboration can be a very good thing. Sometimes, however, something is lost among all of the buzz about collaboration, Web 2.0, and Enterprise 2.0. In particular, I’m talking about the increased difficulty involved on “community” projects.

In a series of posts, I’ll make the case against collaboration. For today, I’ll address some of the benefits of minimizing the number participants on information management projects.

Disclaimers

Now, don’t get me wrong here. I’m a big believer that the whole can well exceed the sum of its parts. Further, many–if not most–large IT endeavors cannot be handled by one person, no matter how talented. Let’s not forget that many organizations may not employ an individual capable of being the single point of contact. Finally, even “one” were possible, it’s typically not desirable. A defection of employee exit can cripple a project of this ilk.

With these caveats out of the way, let’s talk why collaboration might not make sense for your particular IT or information management (IM) project.

Understanding

In my post a few weeks ago, I wrote about how my current project entails an application fraught with superfluous complexity. While the details aren’t terribly important, suffice it to say that my client’s current app is about a two on a scale of one to ten. Its replacement is about an eight.

Mitigating this complexity, however, is the fact that I am primarily dealing with one person at my new client. Let’s call her Kayla. She’s a smart and seasoned professional who knows the following:

• the old application
• her organization’s policies
• the data
• the culture and the key players

Long story short: Since Kayla is stepping up to the plate, I can spend most of my time ensuring that she gets it. In turn, she’ll work with end users after I depart. While I am working with others at her company, she’s made it clear that everything should go through her. She’s not being territorial; she just knows how everyone and everything works there. Like me, she wants the project to be successful and making sure that she’s the “super user” is the best way to accomplish that goal.

Communication, Responsiveness, and Clarity

One of the biggest issues continually haunting IT projects has nothing to do with information or technology. That’s right.  Communication issues are the bane of many data and system migrations and have been for quite some time. Long, essentially pointless email chains often confuse, rather than convey. We’ve all been there. Everyone’s copied because of fear of excluding someone from the loop. Or maybe it’s death by meeting. Regardless of the medium, we’re left wondering what on earth we’re trying to do.

Fortunately, I don’t have to deal with these headaches on my current gig. I know that I can send an email to Kayla or call her up to get an answer to a policy, data, or system question. No large email chains or meetings required.

Accountability

Now, I tend to approach the notion of accountability from the vantage point of a consultant. I love the increased accountability of dealing with a single person. Stop me if this sounds familiar: On past projects, I have had to junk or significantly rework documents, custom reports, mini applications, or system configuration because Person A made a decision that Person B was supposed to make. (Obviously, the “authority” issue is highly related to the previously mentioned communications one.)

Again, I really enjoy being held accountable by one person–and concurrently being able to hold her accountable. It’s one of the main reasons that my current project will, in all likelihood, come in ahead of schedule and under budget. I’ll be the last person to take credit for this. Yes, some of this is my doing, but I can only be as good, efficient, and effective as my clients let me. I can say without fear of accurate contradiction that I’d feel worse about the project if I had to ensure that everyone was at Kayla’s level. They don’t seem to have the same skill set and they sure haven’t participated in the project to the same extent that Kayla has.

Simon Says

It’s rarely a wise idea to staff projects with a single person. From a risk mitigation standpoint, I can think of few more foolish decisions than to concentrate all knowledge and power in the hands of one person, no matter how benevolent, loyal, or sharing. People win lotteries and quit jobs for all sorts of reasons, even in a bad economy.

At the same time, however, it’s important to consider the potential limitations and drawbacks of collaboration. Ask yourself if the potential drawbacks are worth its benefits.

Feedback

What do you think?

It looks like 2010 will be the year of Analytics with advertising from most of the major players and tie-ups between IBM and SPSS as well as Accenture and SAS just to name a couple of high profile examples.  Read a little deeper though and the real business activity gets a whole lot more interesting.

It’s true that most of the focus has recently been on analytical techniques, with books such as Competing on Analytics (Davenport and Harris) popularising terms like “Analytics Competitor”.  Improvements in computing power have also made complex analytics practical on almost every dataset.  However, what is really driving the trend?  Davenport and Harris themselves provide some of the evidence in their book when they identify that one of the most important factors in the take-up of analytics is the presence of a leader (typically the CEO) who believes in the power of analytics and data.  They use in their book a quote, original from W. Edwards Deming): “In god we trust, all others bring data”.

What does this all mean?  Fundamentally the pinnacle of extracting value from data is interpreting it, to do this you need very clever analytics.  To do the analytics, you need great data that is not biased by any management interpretation – that sounds a lot like Enterprise Data Management.  To leverage the analytics, you need an organisation that is committed to using information, learning from the past and applying it to the future – that sounds a lot like Information Management.

2010 is going to be very interesting with the hope that we can bring data, information and analytics to the fore of business thinking.

Jason Sharpe (Telstra General Manager for Collaboration, Knowledge, and Intelligence) and I met this week to discuss an area that we both feel strongly about: the need for standards within and across organizations for the development of reports.  We think this isn’t really an area that any commercial business looks to use as a point of differentiation, rather it is a “ticket to play” for good information practice.

Jason and I are looking for collaborators to develop vendor-neutral reporting templates (building on the existing MIKE2.0 Deliverable Templates) which could then be extended to vendor-specific templates and cross referenced to the MIKE2.0 WBS.  By doing this within MIKE2.0, client organizations can effectively engage their vendors and service providers to finalize these documents for their specific needs which reduces the vendor’s cost of sale while improve the speed and quality of outcome for their clients.

Please let Jason and myself know if you are interested in taking part in this initiative.

I recently caught-up with John Turner, who I have worked with in different capacities for many years.  John is a pioneer in XBRL and Chief Executive of CoreFiling.  We were speaking about Inline XBRL plus some of the material that Mike Bergman has championed on MIKE2.0 recently on the Semantic Web and Open SEAS.  The result is a very interesting new article defining Inline XBRL.  I encourage you to read the article in full, which includes the definition of Inline XBRL:

“Inline XBRL provides a formal specification that governs the production of web pages in HTML or xHTML that incorporate XBRL tagging instructions around specific facts commingled inside the HTML markup. The specification allows the unambiguous and standardised transform of Inline XBRL (often shortened to iXBRL) into XBRL.”

During the 1980s I remember reading for many years in a row that networks were going to be the next big thing.  So much so, that it became easy to become cynical about their potential.  Similarly, many people (including myself) have been talking about XBRL for far too many years, but maybe, just maybe it is starting to come of age.

XBRL (or eXtensible Business Reporting Language to the uninitiated) is a standardised way of communicating business information such as financial statements, regulatory submissions and internal reports.  By using a standard language, you get all of the benefits of any information standard.  The benefits include the interoperability of software, transparency of business rules, simplicity of data aggregation and simplified analysis.  The requirement to learn a new language and the lack of supporting software has, to-date, put many businesses off.

While there have been a number of trials, including most famously the SEC in the United States, I think it is worthwhile to take a few minutes to look at the latest initiative from the Australian Government: Standard Business Reporting (www.sbr.gov.au).  The new SBR website is slick (at least for a government site!) and explains the benefits and initiative well.  It will be exciting to see whether SBR achieves its aims to change business reporting in Australia.