A few weeks ago, when discussing how to justify training for your team, I advocated creating a demonstration project, something that would show your boss the benefits of a new technology. The hope is that he or she will then free up funding for your organization.
After I wrote that column, I got a number of e-mails asking for more information on these kinds of demonstration projects. One of them asked for advice on the politics of such projects: who do you tell in advance, who works on the project, etc.
This really leads more into the arena of an IT skunk works. As you probably know, the original Skunk Works was run by Lockheed and allowed the Air Force to experiment with advanced technology for prototypes of new military aircraft. (By the way, if you’re interested, here are the basic rules used by Lockheed in operating the Skunk Works.) However, the term now refers to any effort by an organization to develop technology outside of its normal processes.
In this column, I’m going to give you some suggestions on how to set up your own skunk works—not so much a physical location, but rather an approach to conducting technology experimentation.
Setting the ground rules
Of course, if you’re the United States Air Force, setting up a skunk works is easy. Start with vast sums of off-budget funding, hire a competent contractor, build facilities in the middle of nowhere, and then post armed guards to keep people from nosing around.
For IT managers, it’s not so simple. Therefore, let’s decide precisely what we mean by the term skunk works. Here are my thoughts:
- Little or no dedicated skunk works budget
- No full-time personnel allocated to skunk works
- No dedicated skunk works facilities
As you can see, compared to the Air Force, this is a considerably more modest effort.
So what’s left? In this vision, the term skunk works refers to "off-the-project-list" efforts to test new technology by redeploying existing assets. Before I get into how to do this in your organization, let me give you a couple of examples of such projects, past and present.
Example #1: From the annals of the PC vs. Minicomputer Wars
Like a lot of IT pros, I kind of backed into the field, riding the PC wave as it entered corporate life. In those days, to be an IT pro meant working on mainframes and minicomputers. The personal computer was widely derided as a toy. At the time, I worked for a regional long distance carrier that used Wang minicomputers for almost everything.
In those days, there were a ton of long distance carriers trying to service commercial customers. Attempting to do competitive rate analysis was a nightmare, as was network analysis (minimizing costs by deciding where and when to establish dedicated circuits between cities to terminate traffic, as opposed to terminating the calls over competitors' lines at a per-minute rate).
One of my first big skunk works projects was to use a PC with a 386 processor (a screamer in its day) running Paradox 3.5 (DOS version) to crunch call records. I think the first report I produced was an analysis of intrastate vs. interstate calls. While the Wang mini was still faster than a PC in those days, the PC’s ability to do on-the-fly queries and custom reports was a huge advantage.
Using the results of that and other reporting, we were able to get funding to set up a database services group, which used PCs exclusively.
Example #2: Linux
Of course, in many ways those old PC vs. minicomputer disputes mirror today’s efforts by Linux enthusiasts to promote the open source operating system. Over the past couple of years, endless numbers of TechRepublic members have posted to our Discussion Center, telling how they used surplus equipment to install Linux-based firewalls or mail servers.
In many of these cases, Linux advocates worked on these projects surreptitiously, hoping to overcome the reluctance of open source skeptics by demonstrating how reliable Linux could be for routine infrastructure tasks. They could then sandbag opponents in department meetings, asking in an innocent voice, "Can somebody remind me again why we’re paying $23,000 for that commercial firewall, when I’ve got one on my department LAN that uses an old Pentium II and only cost me a couple of new NIC cards?"
Some suggestions for your skunk works projects
So now that we’re on the same page regarding what a skunk works project is, here are some tips on how to manage your stealth development efforts.
Document time spent
Noting how much time you spend on a clandestine project is important, for a couple of reasons. First, you need to be able to perform some kind of cost-benefit analysis when you’re finished. Even if you don’t have to directly pay for the time, you need to know how long something took to do if you want to use the project as evidence for organizational support. Second, and perhaps more important personally, once you tell your boss about the project, he or she might be upset that you spend time on a skunk works effort when you have a ton of other work to do. Being able to document all the time you spent on the project could go a long way towards allaying those concerns.
Make sure it’s off the clock
Of course, you can only allay your boss’s concerns if, in fact, your skunk works efforts do not take time away from your "real" work. For that reason, I recommend that all of the time you spend on one of these skunk works projects be off the clock—after or before regular work hours. If that’s not practical in your case, I suggest you fill out a ticket and log the effort on your team’s project list. If you like, you can still be cryptic about what you’re really up to—call it "training." In a way, that’s completely accurate.
Be a scrounger
This won’t be a problem for most of you. (In my experience, IT pros are often packrats—they never want to throw away any piece of hardware or software!) The key to success for many skunk works projects is finding the hardware and software to power the test. For that reason, learn to be a scrounger, like the James Garner character in The Great Escape. If you work at it, you’d be surprised at how much hardware is lying around unused in most organizations—the same thing is true for software, though that might not be as obvious.
Be careful using leased equipment
This is an arcane point, but an important one. Be very careful using leased equipment on a skunk works project. For openers, with a leased desktop, for example, you can’t simply pull the components out and put in different ones without breaking the lease terms. That same lease will sometimes require you to specify in advance what a particular piece of hardware will be used for. Finally, skunk works projects can be hard on equipment—don’t use stuff that will be shipped back to the real owner: the leasing company.
UI counts for non-IT folks (it shouldn’t but it does)
If you’re trying to impress a lot of non-IT folks with a skunk works project, make sure you spend some on the user interface. Most technical people would understand why the UI on a demonstration project would be kind of primitive. Unfortunately, many non-IT managers would view such a UI as evidence that the technology isn’t ready for the prime time, or is not robust enough to support mission-critical applications. That’s not fair, of course, but it’s something you have to live with.
Only involve people who care
I’ll leave you with this last piece of advice. As an IT manager, you can probably force your direct reports to work on any department initiative. However, when it comes to a skunk works project, only involve people who volunteer, and who are really interested in the new technology. It’s tough to find the time to do these kinds of projects. It’s even tougher to make things work if the other folks working on it aren’t as committed to success as you are.