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
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".
- 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.
- 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.
- 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.
- 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 technolpogy issues. If you can start to make them happy,
you are probably working on something that has relevance to your
- 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
- 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.
- 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.)
- 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).
- 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.
- 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.