Anil John
Making Digital Services Secure and Trustworthy

Anil John

Why Should Digital Service Delivery Organizations Conduct R and D?

 Tweet  Share  Comment  Print  Email

If you are in the digital service delivery business and don’t have a program component focused on “looking around corners for what is coming”, you will be blind-sided (it is simply a question of when). So, how can digital service delivery programs avoid this?

Why Should Digital Service Delivery Organizations Conduct R and D?

One answer is an investment in research and development (R&D). But given that R&D is a risky endeavor, it is important to understand both the nature of that risk and the mitigation(s) that can be put in place to ensure good outcomes.

What is Research and Development?

R&D means different things to different people, so let me provide a pointer to the article “The Difference Between Research and Development” that provides a good overview of the continuum of research and development.

Continuum of research and development

The common perception by digital service implementers of R&D tends to focus on the two bookends above, and tends to dismiss the first (Basic Research) as too theoretical, and the last (Product Development) as the place to influence the future.

I agree with the first but would take the position that seeking to influence the future in the Product Development phase is a heavy lift because you are fighting the weight and inertia of in-flight technical, business and strategic choices that have been made in product direction by commercial entities with a profit motive.

While smaller companies and start-ups may be able to pivot more quickly, all commercial entities irrespective of size, will take that decision based on their assessment if a set of risks have been adequately addressed.

The place to address those risks is earlier, during Applied Research and Advanced Development, which typically have a time horizon of 1-5 years.

This is the sweet-spot that Digital Service delivery organizations need to focus on - look around corners 1-5 years to see what is coming in order to figure out what you need, and invest to minimize the risks to the “product” you need such that there is little to no friction when it enters the product development and commercialization pipeline.

Sources of R&D Risk

The literature on the topic, in broad terms, identifies the sources of risk for R&D projects as Operational, Organizational, Technical, Market and Supplier.

Market Risk

In this article, I am going to highlight Technical and Supplier risk, but I would be very remiss if I did not point to an all too often overlooked type of Market Risk, which has to do with technology transition:

"... we often spend 80% of the money on the science and leave 10-20% to try and transition. And in fact, the work factor is the exact opposite. It takes about 20% of the work to do the science and the research, and it takes 80% of the work to actually transition it and commercialize it."

Dr. Doug Maughan on Cyber Security R&D

Do. Not. Put. This. Off.

All too often, those conducting R&D tend to focus on the science to the exclusion of everything else. That is an opportunity to provide the perfect answer … to a question no one is asking!

While I use the term R&D as a shortcut phrase, my internal dialog translates that to RDT (Research, Development, Transition) because without incorporating the transition piece up front (which is based on a clear understanding of operational needs), you are not solving problems but conducting science experiments!

Technical Risk

Some questions that can generate an understanding of technical risk are:

  • Is the technology feasible?
  • What body of scientific work are you building on?
  • What makes this technology or technical approach commercially and socially valuable?
  • What is the gain-to-pain ratio of this approach or technology at this point in time? 3 years out? 5 years out?

BTW, an answer that the current technology is not able to meet the need is a perfectly fine answer to a good RDT organization. It simply opens the door to the question “What does this answer now make possible?”

However, the answer the techology is not able to meet the need is an unacceptable answer to a VC or Commercial Entity seeking a commercial opportunity.

Why is this distinction important? Because many service delivery organizations incorrectly believe that VCs or Product Development organizations are willing to back or conduct the R&D needed to move their idea for a solution to something product-worthy.

The reality is that it would be impossible to get an invitation to a Product Development ball simply because you have been granted a wish by the good idea fairy!

But an RDT investment, made earlier in the lifecycle in Applied Research and/or Advanced Development, can be translated into something with enough fidelity to enter product development where it can attract commercialization opportunities, which in turn allows the organization to acquire it from the market.

Supplier Risk

Some questions that can generate an understanding of supplier risk are:

  • Does the supplier have the intellectual horsepower to tackle the problem?
  • Is the supplier competent?
  • Is the supplier matched properly to the problem? Is there a hammer and nail issue? (“To someone with only a hammer, all problems are nails”)
  • Does the supplier have a viable product and transition strategy?
  • Can the supplier ship?

Competency should be a given. But even more so, it is important to note that while you can have the smartest bunch of people working on a problem, if they cannot execute, if they cannot ship, they are not on a path to success.

More than any other type of work, investing in people and getting the right ones on the bus and the wrong ones off is critical to the success of RDT Programs!

Thoughts on Execution

I don’t have magical, hand-wavy answers here but would instead recommend modeling success and integrating lessons from a variety of communities and disciplines.

Here are some items for your consideration as you move out on your RDT Strategy:

  • Have a clear pain point discovery strategy that follows an iterative, design thinking process:
    • “We think this is the problem we need to solve; to what extent does this match your view?”
    • “Here are the possibilities we want to explore, given the problem definition we agreed on; to what extent are they the possibilities you imagine? Are we missing some, and are any we’re considering nonstarters for you?”
    • “We plan to do these analyses/work/prototypes on the possibilities that we’ve agreed on are worth exploring; to what extent are they analyses/work/prototypes that you would want done, and are we missing any?”
  • Be aware of organizational blind-spots and put into place the appropriate “canary-in-a-coal-mine” mechanisms
  • Establish mechanisms to reach a diverse pool of talented suppliers in a flexible manner
  • Incremental, short duration investments to drive and evaluate minimum viable products
  • Beware the commitment escalation trap; Establish and communicate walk-away criteria up front

… and needless to say, if your organization does not want to be in the RDT business, establish a relationship with an organization that does!

Digital service delivery touches both innovation and mechanical process, and incorporating a forward looking research, development and transition component is a critical and worthwhile insurance and investment to ensure sustained and resilient program success.

Question: What digital service delivery organizations are you aware of that are effectively incorporating R&D into their programs?


Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!

I will never share, rent, or sell your information to anyone. Cancel anytime.

This blog post first appeared on Anil John | Blog ( The opinions expressed here are my own and do not represent my employer’s view in any way.

By on |

Continue The Conversation ...

I would love to know your thoughts on this blog post.
Meet me over on Twitter or LinkedIn to join the conversation!

I am a Public Interest Technologist. I help technical leaders make digital services secure and trustworthy. Learn more »

Free Updates

I will never share, rent, or sell your information to anyone