Recalibrating for Innovation Success

“The barrier to our future is often the very plans we’ve created to get there.”

By now, it should be quite clear there is no shortage of ways for enterprise innovation to fail, and that it tends to do so just as it’s seemingly hit its stride – having advanced into the Build stage. Ironically, not only is this the stage where innovation truly begins to prove its value, but it is also the point at which it is most vulnerable. When we say the majority of innovations find their breaking point during Build, we are not kidding!

There are many ways to go about dispersing blame. Perhaps the innovation team did not vet product prototypes through a sufficient volume of early testers. Or, maybe the company believed a bit too strongly that the size of its innovation portfolio would translate directly to market fitness (an occurrence that comes all too easily in the enterprise environment). More often, however, the most significant barriers lie in the very nature of large-company culture. There is a certain intractability and systematic focus on risk mitigation that, while noble in its pursuit, does not necessarily foster a replicable – or even reliable – path to innovation success.

Barrier One – True innovation cannot be delivered under Fixed-Time / Fixed-Price scope-of-work models

Innovation requires agility and flexibility. To do it successfully, the project must be put in a position to course-correct on a monthly, weekly and even daily basis throughout the build process. Why? Because the entire premise of innovation means the result has be accepted by the market organically; it cannot, and will not, draw success from an overt push to market. Under these conditions, there is no baseline for how long, or how many iterations, it will take to get a final product to a point of market acceptance. You cannot accurately estimate the work on Day One.

Unfortunately, traditional procurement procedures do not account for this level of flexibility. Hardened purchasing professionals always look to marry the fixed-bid model they use for everything else to innovation delivery, but this is a marriage that simply doesn’t work.

To innovate on a fixed bid proposal, you generally need to write-in tens of change requests (and be prepared to pay for them). It is cumbersome, counter-productive, and makes delivering innovation nearly impossible. Fixed bid engagements essentially lock you out from executing the core requirements of innovation done right: iteration and improvement.

Instead, innovation delivery requires an agile-based proposal, which breaks the deliverables into sprints and specific resource commitments for each sprint. There has to be an explicit understanding among all parties that the development team is on the hook to deliver each sprint within its contracted parameters, period, or the buyer has the right to end the project. No questions asked, with no further obligations.

Truth be told, it can be very difficult for someone schooled in traditional business negotiation to come to terms with this concept, and it is probably where innovation delivery clashes most directly with the general enterprise mandate to manage risk. The moment of revelation comes when an enterprise sees that, here, risk management just takes a different tack.

Say no to fixed-bid and time-and-materials contracting when dealing with innovation delivery. It can only lead to disappointment.

Barrier Two – Entrenched belief that development work is still bought and sold ‘by the hour’

Related to the above, enterprises still hold fast to what has become an antiquated belief in ‘man hours.’ Like clockwork, we now expect prospective clients to ask some form of the question, “So, what’s your hourly rate.” Unfortunately, modern, agile-based developers no longer think in these terms because agile is all about delivering on an end goal. The variables that matter have to do not with the volume of time it will take to produce a deliverable, but rather how complicated the deliverable is, how many sprints it will take to get it right, and the delivery timeline. If you are holding the innovation team to a date and specific acceptance metrics, hours become irrelevant.

M3hive lives this model, because we’ve seen how well it works. In a recent example, a client was so excited by what they saw in a ‘first release’ deliverable that the internal team saw fit to hold a black-tie event and invite a pool of potential early users. The crowd interacted with the product, gave direct feedback and provided extremely useful insight, which of course was used to enhance a second release of the product.

In the above, if the contractual terms had not reinforced delivery and acceptance, and if we did not start from a mutual understanding of the end goal and the iterations that would be required to get there, it is hard to say whether the initial sprints would have yielded such engaging returns.

Barrier Three – Critical gaps in project management

Proper project management has unfortunately become a casual victim of the outsource mentality, which pigeonholes external development providers into the role of doing the work you do not want to do yourself. In so doing, enterprises can fall into an age-old trap, and start believing the build stage is but someone else’s problem now. A very dangerous proposition, indeed.

To keep perception gaps like this from creeping in, project management in innovation delivery requires:

• An internal person who is empowered to make final decisions. He or she will guide the iteration plan, and be called upon to remove impediments the external innovation delivery team may encounter;
• A person from the outside strategy firm, who is enlisted to keep the big picture in sight and maintain alignment among all parties; and
• A project lead from the innovation delivery team to manage releases and expectations.

The forgotten glue in this respect tends to be a representative from the third-party strategy firm, who becomes a vital resource when friction occurs between internal expectations and what developers may be creating in the trenches. Many times, the development personnel – the people actually doing the work – do not fully internalize a given client’s culture, and this third-party cog becomes a valuable intermediary.

As a case in point, M3hive works often hand in hand with innovation consulting companies such as McKinsey & Company and Bionic Solution to fill this role on the innovation delivery engagements we conduct.

What’s so indispensable about placing these strategy executives in the mix, we’ve found, is they have generally been embedded in the enterprise for an extended period of time and possess a real feel for internal team nuances, while also bearing full empathy for the developer viewpoint and challenges they experience. Critically, their opinion is valued and trusted by all sides. In fact, they could be considered the Chief Happiness Officer of the entire operation and, from the enterprise perspective, such a keystone is a much-heralded risk management tool.

The bottom line is this: The rules of engagement that allow an enterprise to operate so smoothly at scale are simply not the same as those required for building successful innovation. The traditional model for buying, selling and negotiating software development does not work in an agile-driven process, so enterprises need to adjust the tone of contractual terms to reflect these circumstances. Meanwhile, project management requires more than just the skill of keeping trains running on time. It requires a keen sense of team alignment, and willingness to intercede.

Enterprises who know they need to innovate face a real dilemma. They understand implicitly that they may not be able to move quickly, or meticulously, enough to succeed. Failure is an option, and that is frightening. But rethinking procedures to solve for those barriers can tilt the odds. Your innovation project may even become listed as the favorite.