Guidelines for Success with your Skunk Works project

I’ve been hearing the term skunk works a lot lately, in reference to off-plan projects that are moving forward in all that “free time” people have in the IT department. Sometimes the term sounds slightly perjorative, but I like it when a project I am involved with is referred to in this way.

The term’s origin is well documented, no need to repeat it here. The Lockheed Martin folks made it famous, when referring to technology projects “on the edge”. And I even happened across a CIO magazine article from the olde days that gives a nice airline magazine view of skunk works inside of your IT department.

Over the years, I’ve worked on some “side projects” of my own, and I’ve found these guidelines helpful – especially when your project represents a departure from “The [your company name] Way”.

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.
4. Embrace the Skeptical: Switching now from the folks who implemented the existing technology, to the folks using the stuff. This group has undoubtedly spent long hours detailing out the shortcomings of the as-is, and the assumed inadequacies of all potential solutions (save, perhaps, for the $ilver Bullet$). Know, however, at the heart of their murmuring is the defective valve you are trying to address; work with these folks to understand the real process and/or technology issues. If you can start to make them happy, you are probably working on something that has relevance to your organization.
5. Adopt some Agile: The lack of dedicated time and resources, and the inability to gather tight requirements, suggest an agile/scrum sorta development approach. Deliver your solution in lots of small releases. Add a few features at a time, wring out the bugs as you go. Keep your bites small, so you don’t get overwhelmed by a thousand moving parts that need to come together. And, since we’re usually talking about changing some deeply held beliefs, it’s easier to introduce change when it’s done slowly.
6. Change their Minds on the Screen: This is where #4 and #5 come together; the skeptical can be turned when they can see on the screen what they’ve only dreamed about. You can also [hopefully] get some credibility with the Skeptical when you can realize in working code what many have only theorized about.
7. Keep it Simple: Ok, before #6 gives you visions of developing the Next Big Thing, go back to #5 and read it again. Evolutionary can be as powerful as revolutionary, so focus on delivering value incrementally. (My latest over-used metaphor for this is baseball strategy – a series of singles and doubles vs. going for the home run every time.)
8. Beta is Better: Google has perfected this approach; call your early-release software Beta as soon as possible, and as long as possible. No one should be able to complain about the “beta” version of anything – it is a free pass for those little bugs that make their way through (again, embrace #5).
9. Think Two Releases Ahead: This one isn’t as easy as the previous ones; you need to have a reasonably clear vision of where this is all going – but don’t tell everyone about it quite yet. Some of the debugging you are doing in your early releases (#5) may impact some of the design ideas you think will work. Also, you don’t want to let up on the frequency if you can help it – don’t give the Skeptical (#4) time to build up another set of arguments in resistance.
10. Install and Train In Person: Don’t kid yourself – nobody does decent training material or user documentation until version 2.0. Besides, the interaction with the true end-user of your new technology / process will unearth the real requirements; in my latest project, I have never introduced an incremental release without getting at least two new requirements back.

You need to realize that bootstrapping technology as a startup – within a corporation or out on your own – is innovation at it’s best, and innovation can get a little messy. Deal with the grey until you get a foothold – you can always shore up your process when the idea takes hold and your side project graduates into a more formal structure.