Required Answers before an Undertaking

I’m currently looking through some best-practices as we look to expand (again) our web analytics and reporting capabilities. There’s lots of info out there about warehousing great swaths of log data, navigation funnels, user behaviors.

“Warehouse” projects I’d been involved with previously had been owned and driven by Technology groups. When I ran across this article, it reïnforced a simple message that’s true for implementations of almost any size: Before you start building anything, ask the Business about their primary goal. From the piece:

statcounter for cybersoc (nov 07 to nov 08)
Creative Commons License photo credit: robinhamman

Business L (person) – I need a data warehouse!
Geek – Why?
BL – Because I need to know stuff.
G – What stuff?
BL – You know, likes sales data and stuff.
G – Can you express that as a single, English question?
BL – I want to know how many of which products we sell in a month, what it costs us, and how much we sold it for.
G – So you want to look at quantity, cost, and purchase price?
BL – Yes.
G – And you just want to know what was bought , when it was bought, and where it was bought?
BL – Exactly.
G – No problem.
BL – Wait, I need a seperate report sorted by sales region, one for product line, one for…
G – Easy turbo. Let’s just start with one specific question and see how that works before worry about any more.
BL- Thank you very much. I find your responses constructive and supportive. I look forward to working with you.

Can’t you produce a simple prototype very quickly on that information? Wouldn’t it answer a lot of questions that are all basically variations on a single theme?

Can’t you just extract a sample of data and slap it on your dev box and go back to BL in a day or two and show him something?

DON’T Build a Data Warehouse

My project management philosophy is simple and effective:

  1. Tell folks what you plan to Do
  2. Do it
  3. Tell them what you’ve Done

Before you can effectively let the business know what you plan to do, it’s beneficial to get as solid an idea as possible of what the business thinks needs doing.

On this current analytics project, I’m the primary client / user as well as the one building the solution. Even so, I’ve let my team know what my plans are and why; I’ve got their buy-in as I’ve already produced several sample reports – and related actionable suggestions – to demonstrate the kinds of insights and intelligence I’m working to produce on an ongoing basis.

I can now proceed accordingly, produce regular results and suggestions, and hope to see those suggestions put in motion.

I recommend reading the referenced article and especially the comments beneath it. Don’t think it applies only to datawarehouse projects – the ideas work for any number of projects.

Valuing “Institutional” Knowledge

It seems to me that institutional knowledge (IK) is like common sense. Much as there is rarely anything ‘common’ about common sense so is there rarely anything remotely ‘institutional’ about institutional knowledge. Most often, IK is the province of your more rabid ivory-tower, b-school types who use IK as an excuse to justify chairing more meetings or your application development guys, who think that storing all the emails on a project, most of the presentations, and some versions of the code is IK. It’s neither.

At its best IK acts like a corporate research library devoted to the policies, practices, products and history of an organization. It is accessible, germane, trusted and utilized. It is the corporate memory and a reflection of how the institution thinks and solves problems.

As a new generation of collaboration tools begins to roll-out (Google Wave , Sharepoint 2010 and others) there’s the usual buzz going around about how these tools will allow companies to better leverage IK on projects and usher in a new age of business productivity. (cue: images of sunrise, fanfare, children playing, etc.) While it’s true that these apps may represent the latest and greatest in collaboration tools the limiting factor on their benefit to your company is likely…wait for it…your company.

You see, I think IK has value only if your company is organized around some basic precepts:

  • a company CAN learn from internal history
  • failure has value
  • success needs formal review too
  • project administration is important

If your organization doesn’t share and prioritize…institutionalize…these precepts then whatever is preserved by collaboration software will likely be wasted.

These four precepts interact with IK in some very basic and important ways. Our tendency to emphasize the differences in today’s marketplace from previous ones gives no credence to the fact that consumers (i.e. the people with the money) behave very similarly today as they did 30 years ago. Good ideas need to be remembered and periodically reviewed so that when business conditions change, they can be implemented. If your company doesn’t respect the ideation of those who went before IK tools won’t likely do as much for you as they could.

Now, in my experience, when a brilliant idea fails it’s proud-parent is rarely called upon to give a formal write-up as to why everything went South – in fact the brave soul is usually shunned, marginalized, and if the flop was big enough, rapidly terminated. This is a great way to waste IK. All of the research, documentation, assumptions, presentations, etc. should be handed over to a corporate curator, packaged, cataloged and interred in a corporate archive. The key decision-makers should be interviewed and their learnings recorded. The company spent money, usually millions, on this project and it doesn’t even want to give the project a formal burial. It’s a lost opportunity.

However, what is worse in my opinion, is when a company has a breakout success, fails to understand fully why it happened, and blithely assumes that its success was due to its brilliance rather than the marketplace. If you do not capture the IK on why something worked it can be as risky as avoiding something because it failed once.

Last, project administration; the note-taking; the meetings; the emails; the documentation; more meetings; the uploading; the versioning – project administration amounts to discipline. This is vital to utilizing IK in the future and is probably the least respected component of a successful company. Don’t confuse time worked, emails sent, presentations produced, meetings scheduled, etc. with project administration, what I refer to here is the lost art of taking all the dross of a project; filtering it to understand what happened; annotating when and why decisions were made; preserving and editing the notes…and throwing the rest away. Editing is important to the successful application of IK to new situations. If someone has to sort through a mess to learn something then not only is their time wasted but so it the effort and expense that went into collecting and storing it.

With the advent of a generational shift in collaboration tools, we are undoubtedly on the verge of a new era of workplace productivity (again). This time, when you are considering new collaboration tools give some thought to the way that you collaborate.

• Does the organization have an institutionalized approach to collaboration or are you just posting individual efforts to a glorified bulletin board?
• Are you preserving the hard-fought lessons that you are learning in a rough economy or are you just filling up space on a server and calling it productivity?