Expertise, Skunk Works, and Project Management

By Dennis D. McDonald

To follow up some earlier postings I'm working on an article defining requirements for applying expertise management processes and technologies within the enterprise. I've been researching concepts like "expert management systems," "expert location," and "expert locator systems." My goal is to get a handle on the state of the art as it might be impacted by current social networking and collaboration technologies.

Most of my research has been web based and includes the use of various general search engines (Google, Kartoo, and Clusty) as well as blog-related tools (e.g., Technorati, IceRocket, and Raw Sugar). There's a lot more going on than I had originally expected and there also appears to be a lot of academic research as well.

I'm trying to narrow my search somewhat by paying special attention to products, projects, and actual experiences. It was in the context of this focus that a recent blog posting by James MacLennan caught my eye. He has an interesting post in his blog cazh1: on Business, Information and Technology titled Guidelines for Success with your Skunk Works Project.

If you don't know what "Skunk Works" refers to, I recommend you read the book SKUNK WORKS by Ben R. Rich and Leo Janos, published in 1994 by Little, Brown and Company, ISBN 0-316-74300-3.

MacLennan's "day job" is director of IT for a large manufacturing company.  He writes in plain English about topics like consulting engagements, who really pays for IT infrastructure, documentation quality, and master consulting agreements. In his "skunk works" post he describes ten rules for project management related to projects that are run by IT "off the edge." These are the ones that are examples of innovative solutions that sometimes turn out to be inherently messy. Here I quote the first three of MacLennan's rules:

1. Involve the Resident Experts: Someone may have a strong sense of ownership towards the turf you are invading. Even if you don't intend to, the Resident Expert, Owner(s) of the Architecture, Standards Team, whatever, may perceive that you are making a "hostile move" - so head off the soap opera before it starts. Bounce some ideas off their heads, but most of all, make sure they know you are thinking about doing something before it surprises them.
2. Listen to the Resident Experts: You should realize that Things Are The Way They Are because someone has tried alternatives before. There is value in understanding the current architecture and standards, if only to jump start the learning process and (hopefully) avoid some blind alleys.
3. Don't Listen to the Resident Experts: On the other hand ... often times, folks get comfortable or complacent with the status quo, and aren't aware of advancements in technologies that may have previously failed. Or, they have invested a lot of time in the as-is; a change might be perceived as invalidating their previous thought. Think of it this way - it's your turn to earn some cuts and bruises working through the new stuff.

Clearly what he's talking about here is the real world of organizational change. A "skunk works" project, while inherently somewhat secretive and "off the radar," still has to answer the question, "whose ox will be gored if this project is successful?" In fact, I'd go so far as to suggest that IT departments shouldn't be involved in "skunk works" projects that don't cause somebody heartburn -- otherwise, what's the point?

Regarding the role of the experts, MacLennan's rules do suggest that experts play different kinds of roles depending on the nature of their expertise and on their real or perceived relationship to the activity for which their expertise is relevant. 

Ah, there's that word "relationship" again. That's a good "Web 2.0" word, don't you agree?

What kinds of relationships should an expertise management system in the enterprise take into account? I don't have an answer to that question; that's the type of thing I'm researching now. But it seems to me that an expertise management system could benefit by taking into account information about a variety of different relationships, e.g.,

• The relationship between the expert and his/her knowledge (e.g., how it was gained, how it is exercised, and how it is described)
• The relationship between the expert and the person seeking the expertise (e.g., does a relationship already exist directly or via someone else in the organization?)
• The relationship between the business units or departments that employ theexpert and the expertise seeker.

As MacLennan's post points out, such relationships can strongly influence the role an expert can play in a project's success -- even when the project is a "skunk works" project that is being run with less than normal publicity and oversight.