The smell of the skunk is a good thing when you need a Disruptive Product to power Growth – Part 2

Summary of Part I

We have all seen where logical, incremental innovations are not going to yield the growth our companies periodically need, or desire, which requires Disruptive Initiatives.  A Skunkworks is designed to deliver disruptive service and products, with minimal overhead and disruption to BAU Operations.

Now, on with our discussion…

What are the Thresholds to help us know when to employ a Skunkworks?

Threshold #1 – Ask “Is this going to innovate or will it transform the business and completely invalidate my competitor’s sunk costs and business plans?  Is this a ‘new and improved’ moment or a brand new product category or approach to target customers   Do I need this quickly or can this bounce around for a while as we polish it?”

We all like to think we work on only the best and newest stuff but, in reality, a lot of our initiative portfolio focus on improving ongoing operations, or growing the business by doing more of the same at lower cost. Rarely are our initiatives a quantum leap into a new and explosive-growth trajectory.   Let the BAU structure handle the former, and give the latter to the Skunkworks. For example, Sony was iterating and innovating the Walkman (Regular, Sport, etc.), but then Apple came out with the iPod and changed everything. Everyone says iTunes is the game changer, but Sony has had a long history in the media business –they just didn’t think disruptively.

Threshold  #2 – Ask “Whom do we have to staff this new type of group? Do I always need a cast of thousands? Where do I house this group?”

As a broad rule, an ‘A’ project must be led by an A-Player.  A-Players can hire and retain other A-Players.  B-Players hire and retain unambitious B-Players or even C-Players, which means you’re potentially betting a strategic initiative on those very resources least in demand by others.  Therefore, go with only A-Players from top to bottom.

For disruptive initiatives, there’s a caveat here.  By an A-Player, I don’t necessarily mean the brightest in an SAT sense – I mean most creative, and quite frankly, most flexible and resilient.  Combine that with a self-motivating and curious personality appreciative of the chance to do something special, who does not feel they inherently deserve to do it, and you have your super-stars. Pick people who have handled working hard to achieve a meaningful goal, the criteria not being knocked-down-percentage, but the number of times they got back up, stifled a cry, and went back at it, only smarter. That Silicon Valley rule of thumb “fail early, fail often” works, only, if you add “and do not repeat the same screw-up twice”.  As Steve Jobs determined, you needed somewhat civilized smart renegades, not smart functionaries.

Not every initiative needs hundreds of players and disruption initiatives are best handled by a small group in the Skunkworks.  We have used as few as 3 on highly focused single process improvement  and internal corporate change initiatives, 20 on new software products and over 30 on major product creation and rollouts, including in-out specific SME’s, such as Compliance and Legal.  Finance, however, has to be a full time member, as does Sales and Brand Marketing, and beware of any so-called disruptive initiative where the major Go-No Go Gate is Risk Management – it shows the organization is not ready, culturally, for this kind of breakthrough. Not to say Risk and Compliance are not key factors, but they are not the prime factor; they too have to be creatives. A Cardiologist friend of mine tells how most of his patients give him a degree of push-back on lifestyle changes, but then are full-out fanatical after a heart attack – they have to disrupt their BAU way of life.  If you are ready for disruption, get to it with the smallest group possible, at the least management overhead.

Where do you house this group?  Note I didn’t say  ‘virtual team’.  If you want BAU productivity, the studies show working remotely is fine.  As someone who often deals with virtual teams, let me assure you they are not very good at creating new, revolutionary, things. If you want disruptive results, the team must interact informally and continuously,  i.e., the people must be co-located.  My suggestion is to take them out of the HQ/Campus bubble and co-locate as close to the target market as you can.  Nothing beats learning a language by total immersion, same for producing disruptive results.

Threshold #3 – Ask “Has someone already figured out how to manage a disruptive initiative? I don’t have time to reinvent this”

Listed below is my adaptation of Clarence “Kelly” L. Johnson’s cardinal rules for his original Skunk Works.  My edits/changes are italicized.  These rules work, no need to reinvent, just adapt.   The key, as we mentioned in a previous post on this blog, BAU (Business As Usual) innovation processes could not work given the timeframes and criticality of these critical initiatives, and so he adopted a novel approach; the BAU factory then built those planes on a massive scale.  We can’t run a breakthrough initiative using the same pace, people and PMO’s as we would employ on something entirely more routine and perhaps, linear and predictable.

1. The Skunk Works Program Manager must be delegated practically complete line – responsibility control of his program in all aspects. He should report to a division president or higher.
2. Strong but small project offices must be staffed by the smallest possible combined Business, Content/Branding, Technology and Operations team.  They must have line-decision power, not just focusing on reporting.
3. The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called BAU project).  KISS means, here, ‘Keep It Simple, Small’.  Large groups mean added wasted time managing the larger group. They must be co-located even if virtually (no other responsibilities but this program)
4. A very simple specifications and design release system with great flexibility for making fast changes must be provided. Let them develop their own methodology, based on Agile and Xtreme Management principles.
5. There must be a minimum number of reports required, but important work must be recorded thoroughly. At the end, information and technology transfer will turn an invention into a business.
6. There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program.
7. The Program Manager must be delegated and must assume more than normal responsibility to get good ‘vendor’ bids for internal and external resources on the project.  The Skunk Works Program Manager has the right to interview all potential participants from all departments, with a right of refusal. This does not mean cheapest hourly costs – think in terms of cost per deliverable done-done.
8. The multi-stage BAU testing function/groups, as currently used across the board, and which has been approved by IT, Compliance/Internally Audit and the Central PMO, meets the intent of existing evolutionary BAU requirements and should not be used on Skunk Works projects. Push more basic inspection responsibility back to the originator, and earlier during the development process. Don’t duplicate so much inspection. Fixing Show Stopper and even High to Low defects found after the fact is too recursive.  Fixes made in this manner can easily destroy the application architecture or product design if not done properly (and often they aren’t).
9. The Skunkwork  personnel  must be delegated the authority to test their final product in actual flight, so they have business context and are not developing in a vacuum. He can and must test it in the initial stages, using Testing Forward design concepts and then test end-to-end before transferring Testing to the User Acceptance Testing function (which is more of a certification and hand-off process).
10. The specifications and desired end take-away result must be agreed to well in advance of estimating. The Skunk Works practice of having a specification section stating clearly which important [military] specification items will not knowingly be complied with, and reasons therefore, is highly recommended.
11. Funding a program must be timely so that the Program Manager doesn’t have to keep running to the bank to support business projects. The Skunk Works Program Manager is the paymaster for the project, paying by deliverable upon acceptance.
12. There must be mutual trust between all participants, with very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.
13. Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures. When assigned to the Skunk Works project, they have only 1 boss, the Skunk Works Program Manager. This is easier when the Skunkworks is properly located offsite, and HQ security badges won’t open the doors.
14. Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised.

Threshold #4 – Ask “How soon do we need this? Must we be the first mover in this new space?  Can my existing initiative management capability deliver at the speed required?”

Typical initiative management is an overlay and adds little to velocity – they measure and report it, but either stand on the sidelines or impede speed.  By definition, large enterprises need a homogeneous project definition and control scheme in order to facilitate consolidation into the Enterprise Portfolio view. They are not built to deliver. We know of a financial institution where the Central PMO Project Master Data Schema comprises hundreds of elements, with all projects/programs being forced into this schema.  Set up alone can take weeks for various approvals and rework.  This approach is solid for monitoring BAU programs, where you have done these x-times before and other than a few peculiarities, you can do this in your sleep if necessary. Speed is not a major consideration, and so some companies set up a War Room instead.

War Rooms are fun. I’ve created and worked in several, and the excitement of the very name is kind of catchy. They are excellent at providing a single version of program/project status, particularly when multiple PMOs are involved.  The issue is, as with the standard PMO described above, War Rooms are reporting and not actions oriented and, therefore, do very little to bring successful results.  They can report late dates just as well as they can report on-time results. They leave it to the Management to interpret the data, which may be out of their experience-zone.  War Rooms do best in a heavily matrixed environment, functioning well as an overlay and are often imposed on a failing program when Senior Management doesn’t fully trust anyone anymore and demands their own view.

Skunk Works are all about fast, coordinated action – when you need a completely new, fresh, and fast paced solution, this is your organization structure of choice.  Reporting is strenuous, but only as required. Management layers are thin, and the organization is flat, but there is the 1 person who is in charge of each initiative, from funding to deliver and sign-off.  They are not matrix friendly – no one can hide by being a member of some larger committee.  The overall program management capability is adapted to the faster pace, and directly empowered to manage the potential impact of unknowns and even unknown unknowns. A Skunkworks has to be self-contained, with all required skills and resource levels dedicated to an initiative.

In Sum,

Choosing how to run innovation requires deciding upon the degree of linear improvement vs. disruptive breakthrough required, and the time frame in which you need it.  It depends on your deciding to be an evolutionary vs. a revolutionary company, of having others respond to your vision, envying your EBIDTA and P/E ratio, your competitors shocked at how their financial and operating plans just became irrelevant. To continue our analogy, in fighting for business growth, it’s almost always better being the skunk and not the dog.

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC, http://www.growroe.com and is one of their senior turnaround leaders/CROs, Program Rescue and Interim Executives with over 25 years’ experience reshaping companies, Operations, IT/Systems Integration and key initiatives. Return on Efficiency, LLC specializes in those companies and initiatives where technology is the primary means of service delivery and revenue creation.  He can be reached at richard.eichen@growroe.com