Cows in the Mist

With the first generation of the “oprations dashboard” and the third or fourth generation of the daily activity report mostly functional, it’s time to accomplish some actual business performance and operational quality visibility.

Looks like the goal for this quarter is to refine our metrics, start delivering them regularly, and drive operational change through better information. Ah, nirvana.

My personal goal is to write more about it than I did last quarter, which, considering the light volume here, should not be too difficult. Another personal goal is to write a white paper on the subject, probably focused on business performance and operations reporting on a shoestring, as a shoestring is what we’ve had to work with here so far.

After three months of thinking, planning, and a little bit of doing, I am seeing positive changes in our business as a result of more effective application of information.

Two weeks ago, I was asked to slightly alter one of my daily reports. The impact of the change has spurred the business on dramatically. We are now able to directly impact our partners’ behavior, on a daily basis, based on new information and an understanding of the trends in day-to-day operations.

It’s gratifying to see an actual, measurable impact of business intelligence on performance. My working definition of knowledge has been “actionable, measurable information.” Armed with this idea, we have been able, over the past two weeks, to turn performance around and see a significant increase in what will eventually become revenue numbers. Looking at near-term historical performance has allowed us to change the future.

Understanding where your current state comes from has practical relevance to defining where you will go next. As George Santayana said, “Those who cannot remember the past are condemned to repeat it” (Life of Reason, “Reason in Common Sense.” Scribner’s: 1905. 284 — I admit I am indebted to Google Answers for that reference).

The side-benefit is that, in this case, it also validates the information anarchist — I mean “senior reporting analyst.”

It looks like I’m going to be able to implement some of my ideas regarding knowledge systems. I have provided my first draft requirements document for our Operations Dashboard, and while it is, in my estimation, incomplete, it is a start. There are systems to be built underneath the Dashboard that will be where the real fun is.

To generate some of the very useful dashboard information, we need an issue tracking system. Coming from a software project background, this seems to be a no-brainer for me. I was surprised when my supervisor had not heard of my two usual suspects — FogBugz and Bugzilla. That was when I realized I’m not working with technologists anymore.

Bugzilla is a philosophical favorite, if only because it’s open source and was the first issue tracking system I ever deployed. However, FogBugz’ ease of use and overall simplicity, along with the predilection for commercial software that big companies often have (plant that tongue firmly in your cheek), make it the likely front-runner for our shop. If I can customize it to present itself as an issues/enhancements/process tracker more than a bug tracker, I think it’s looking good. And it’ll be much easier to deploy than Bugzilla. Sorry, guys. While I’m impressed with the feature-set, I think it’s too much for a non-software organization to use. Besides, Joel Spolsky’s philosophy of simplicity ultimately makes better software.

But why are we tracking issues, anyway? In the world of software development, it’s obvious. You have to find and fix bugs, and the best way to do so is with a structured, repeatable QA process and a system for managing it. That way nothing falls off the table. As it turns out, other kinds of systems have bugs, too, but they call ‘em “issues” instead. One of the easiest ways to measure operational performance is to monitor trends in operational issues. If the number of open issues goes down over time, and the time to resolve them also goes down, you can figure you’re doing pretty well. So that’s one of our Dashboard metrics. Putting an issues management system in place beneath the Dashboard puts some structure into the issue handling process and allows tables in a Word document to become useful items for counting and collecting, centralizing the management but minimizing the overhead. Naturally, such a system should be web-accessible for ease of use. In the current technology environment, this is almost a given.

In the end, using a centralized but openly accessible issues management system accomplishes my twin goals of creating measurable, actionable information while encouraging accessibility. Everybody wins:

• The Dashboard treats the issues system as just another data source
• The executives get to see meaningful trends
• The operations team has a central clearinghouse and process for resolving issues

Ultimately it means I win, because I have less day-to-day reporting to do.

Having some interesting conversations with people in the office about the nature of organizational knowledge. Everyone is surprised to hear the Delphi Group stat about how 80% of an organization’s knowledge is locked up inside the heads of its people. I was, too, initially. But anecdotally I would argue that I have spent the vast majority of my “seeking” time delving not into information systems, but into people’s heads.

And I’m thinking now, about knowledge management. That phrase implies a structure that isn’t necessarily a good thing. I prefer to think of it as knowledge accessibility. The goal of any knowledge-focused systems project should be to make knowledge more accessible to those who need it. The management of knowledge grows out of the accessibility of knowledge.

It took me three days and the assistance of another person to get my hands on a document describing a set of business rules that are common across the entire organization. This should not happen. There is a knowledge accessibility problem here that I think we can solve. Easily accessible, accurate knowledge information can save a company so much money! It’s mind-boggling. The average knowledge worker, according to Delphi, spends 30-60 minutes per day (270 hours per year) “looking for people or information to help solve business problems.” I know I spend much more than that right now. I don’t have the reference in front of me, but I’ll dig it up.

I’m going to push and poke and prod until I get the go-ahead to put a pilot program in place. I already know where I want to put it. I just need a web server, time to train the team, and some marketing assistance. In three months, it will develop into an integral component of the organization’s communication infrastructure.

I have not spent much time in the corporate world in the last five years.

That is one of the things I’ve learned in the past three weeks. Perhaps my biggest challenge is going to be learning how to fit in. I’m a nice guy. I play well with others. I have good social skills. But wow! I’ve spent five years either starting companies or working in and around startups. I have been somewhat spoiled with the requirement to just get things done. It’s curious that one of the aspects of this job I like best — having real co-workers and colleagues again — is also something that makes it the most difficult.

Once it was clear that I’ll have to work hard to figure out the rules of the game, I started watching other people play. One woman, in particular, seems to be very good at working in this environment. She is a great communicator, good at running meetings, a facile speaker, and talented at managing relationships. She’s one of the consultants who are part of the Wholesale group, and I’m going to be paying a good deal of attention to how she works.

Another thing I’ve learned over and over and over in the last few years is that I have much to learn.