How to: Manage a successful skunk works project

del.icio.us Tags: project management,skunkworks,skunk works

My recent experience with discovering, evaluating, and evangelizing Office Communications Server at Extend Health has been great in many senses.  Many projects fail or are axed in their infancy stages.  Some projects probably deserve to be axed at that stage – one of the primary principles of brainstorming is that you entertain all ideas, even the bad ones.  But what about the projects that shouldn’t fail at that stage?  What about the project that are simply struggling to get off the ground and deserve a credible pilot?

I would contest that many projects fail in the idea/skunk works phase because of management failures.  I’m sure many managers of skunk works projects have the best intentions and are qualified managers, but managing a skunk works project is different than managing a sanctioned project.  I scoured the Web (after the project had moved into pilot phase) to see whether there were any documented best practices for managing this type of project.  I didn’t find any distilled, coherent best practices repositories, but I did find some good material that should be referenced here.

Martin Tate had the most to contribute as far as I’m concerned.  He posted a presentation called Implementing Best Practice – A Different Approach, Using ‘Skunkworks’.  In this presentation, he details what skunk works projects are and some of the classic examples (including 3M’s Post-it Notes, Audi’s Quattro, DuPont’s Kevlar, Ford’s Mustang, IBM’s first PC, and the original, Lockheed Martin’s SR-71).  [Note: there weren't any citations, so I'd encourage you to do your own research on those examples.]  He also included several bullet points that just happened to be true of the project I just completed, which was probably dumb luck on my part.  He says that skunk works projects should:

• Like the customer
• Start small and build up
• Maintain low visibility
• Find senior sponsor
• Manage the approvals process
• Create team from the right people

Judy Artunian also had some excellent input in her article for ComputerWorld entitled Skunk Works: The Sweet Smell of Success.  She adds these recommendations:

• Handful of employees with knack for taking a fresh look
• Keep the operation under wraps
• Demonstrate alignment with business objectives
• Keep tabs, but don’t impose a schedule on the project

Finally, Ken Smith blogged about skunk works projects and said:

• Don’t allow skunk works projects to delay normal projects
• Check with product & project/product management first
• Be ready for disappointment

I think the two things that really went right for this project were the fact that I had the CTO as my corporate sponsor, and the fact that I released information at a controlled pace.  I firmly believe that if I had disseminated the information as rapidly as I gathered it, there would have been an overwhelming and sometimes inaccurate flow of information out of the project.  Therefore, if I were to list my own bullet point best practices for skunk works project management (including rehashed versions of points above), this would be it in order of decreasing priority*:

1. Think like the customer (even if the customer is internal)
2. Demonstrate alignment with business objectives
3. Don’t volunteer to manage a project you don’t believe in
4. Find a corporate sponsor who believes in the project (or at least understands its importance and believes in you)
5. Define a series of informal milestones to serve as gating factors for going forward
6. Maintain low visibility
7. Disseminate information at a controlled pace
8. Keep in mind that only a very small percentage of skunk works projects succeed; balance cost-benefit ratio constantly

* If your project doesn’t take into account the first four objectives, don’t bother.  Scrap it and move onto something with more business value.

The $2 million Office Communications Server wager

del.icio.us Tags: microsoft,office communications server,enterprise voice

The company I work for, Extend Health, is currently experiencing the best type of problem: rapid growth.  As many are aware, unchecked or overly rapid growth can sound a death knell for companies.  One potential reason for this correlation is the speed at which decision makers must make decisions.  More decisions are part and parcel of a larger company, but the additional staff necessary to make additional decisions generally lags behind the decisions themselves.  This leaves additional decisions to be made to existing decision-makers, which ultimately leads to a shorter decision lifecycle.

This past year, our company grew 10x in year-over-year numbers.  We did more business in a few days at the start of Medicare season than we did in the entire year previous.  We hope to grow another 4x this year.  This type of growth is putting a significant strain on our existing system, a Cisco UCCX with a few integration pieces installed.  For the past month, we have been evaluating two alternative solution: a Cisco UCCE with more integration servers, and an Avaya solution.  Both solutions are flagship contact center solutions, but they carry a hefty price tag: a low estimate puts the solution around $2.5 million, with a final figure more likely to come in above $3 million.

Part of my job is to review solutions and report on their overall ability to integrate into our environment.  Part of my nature is to add commentary on how viable I feel the solution to be.  As I was researching the Cisco solution, I stumbled across a newer offering: Microsoft Office Communications Server (OCS) 2007.

Microsoft Office Communications Server 2007 was launched not six months ago on 16 October 2007.  The launch was traditional Microsoft strategy: conquest through partnership.  Microsoft’s current claim is that it isn’t there to replace the PBX – yet.  As such, it has strategically allied with a number of hardware vendors such as Nortel, Polycom, Ericsson, Mitel, Dialogic, Audiocodes, and more.  The full list of sanctioned hardware vendors can be found at http://www.microsoft.com/uc/partners_hardware.mspx.  In short, Microsoft partners with hardware vendors for one of two reasons:

1. Connections to the public switched telephone network (PSTN).  No one in their right mind would claim that Microsoft is a telephony expert, especially when it comes to the PSTN or PBX spaces.  Microsoft has aligned itself with hardware vendors that handle nailing down calls and releasing calls when finished.  Microsoft has also worked diligently to leverage the feature set on PBX systems to supplement a weak feature set of an initial offering.  While there are plans to implement features like music on hold, call park, etc, Microsoft simply integrates with existing PBX systems at this point to achieve features it lacks.
2. Handsets/headsets.  The telephony paradigm has not changed significantly in 130 years.  People have used hardware to hear, speak, and initiate/terminate calls.  While the paradigm is changing with the advent of softphones, some people prefer to have the comfort of a traditional telephone set.  Microsoft has partnered with a few vendors (Polycom, Nortel, Jabra) to deliver a telephone experience more in line with traditional telephony.  Mind you, these aren’t your average telephone sets: they have fingerprint recognition, colorful presence indicators, and more!

Microsoft’s forte is providing a solid, well-integrated foundational software layer.  Establishing partnerships for hardware is a must at this point in time.  With the partnerships, Microsoft is able to offer OCS as a truly profound communications platform.

What Microsoft already had a strong background in was collaboration, e-mail and instant messaging, presence, and pervasive integration.  Microsoft Word, for instance, has tight connections with Sharepoint, which can be consumed as an RSS feed in Outlook.  Microsoft, with the delivery of OCS, integrates all the same familiar desktop software with the OCS system, essentially exposing presence and the ability for instant communication from Word, Outlook, or Sharepoint.  Exchange gets the ability to store voicemail and archived IM sessions, meaning you have your entire communications history in one place.  You can initiate a call to the author of a Word document, from the document.  You can start a video chat with someone in a discussion thread on Sharepoint.  The depth and thoughtfulness of the integration alone are sufficient to make a solutions-oriented person take pause.

What Microsoft didn’t have was enterprise voice.  In this context, enterprise voice means that we have lots of inbound and outbound calls.  There was voice chat and even video chat in earlier versions of Microsoft products, but those sessions were limited to internal conversations.  OCS leverages the hardware partnerships mentioned above to add the ability to deal with inbound and outbound calls as well.

I’m not certain that OCS is viable for us.  Our business is critically dependant on enterprise voice: we expect to hit a peak of 10,000 calls in an hour this fall.  However, I have taken significant note of where OCS is at and will continue to investigate the solution as rapidly as possible.  One thing is certain: with an estimated implementation-complete price tag of $500,000 for a jaw-dropping solution that we can build on top of, we’re taking this very seriously.

Not a zero-sum game

del.icio.us Tags: alignment,communication,game theory

Game theory is a branch of applied mathematics employed in making high-level strategic decisions.  There are a number of well-known applications of game theory, one of which is the zero-sum game.  A zero-sum game is one in which the sum of all participants gains and losses is zero: that is, each participants gains or losses are exactly offset by other participants’ gains or losses.  I have had the privilege of working for a number of noteworthy companies, each of which had their own unique perspective on IT-business alignment.  It’s unfortunate that many of these companies treated alignment as if it were a zero-sum game.  At the other end of the spectrum are the “synergy” companies.  These positive thinkers portray the IT-business relationship as centered in a radiant beam of beautiful energy shining down directly from heaven.  Doves flutter, angels sing, and IT and business just work harmoniously.

The truth is that aligning business and IT is a lot of work.  Coming back to game theory, there is a better paradigm for this relationship: the prisoner’s dilemma.  The prisoner’s dilemma is classically stated as follows: Two suspects, A and B, are arrested by the police. The police have insufficient evidence for a conviction, and, having separated both prisoners, visit each of them to offer the same deal: if one testifies for the prosecution against the other and the other remains silent, the betrayer goes free and the silent accomplice receives the full 10-year sentence. If both remain silent, both prisoners are sentenced to only six months in jail for a minor charge. If each betrays the other, each receives a five-year sentence. Each prisoner must make the choice of whether to betray the other or to remain silent. However, neither prisoner knows for sure what choice the other prisoner will make. So this dilemma poses the question: How should the prisoners act?

Prisoner A realizes that the best case scenario is for them to both stay silent and spend only six months in prison.  The thought comes to him, however, that prisoner B may betray him.  If the B betrays him and he stays silent, he’ll spend 10 years in jail.  If he betrays prisoner B, he’ll either go free or only spend five years in jail.  This results in a Nash equilibrium, which is a fancy way of saying that more often than not, both prisoners will betray the other.

It frequently seems as if business and IT find themselves in the same scenario.  As an IT guy, I have harbored more than my share of grudges at what sales people make (both promises and salary).  The thought surfaces, “They wouldn’t have anything to sell if it wasn’t for me!”  I’m sure the equivalent thought surfaces on the business side.  But despite the analogy to the prisoner’s dilemma, there is a fundamental difference.  There can be communication between business and IT.  Although it is arguably as difficult as facilitating communication between prisoners in different cells, communication between business and IT can be facilitated and can create a synergistic relationship.

The intent of this blog is to chronicle one IT guy’s attempt to understand and communicate across the divide to the business side.  As such, there should be very few technical posts here that lack a statement of a business case.  And maybe, just maybe, someone reading this blog might someday hear angels singing.