Do we understand RISK as it relates to delivering technology?

Risk- the chance that things won't turn out well, or uncertainty that they will.

We commit to economic activity if we have a rational expectation of a positive outcome - the product of the effort will have financial value that exceeds its cost by some multiple.  Build a plan, weigh the risk, make the decision, Drive.  Many of us are strongly driven to make things happen once that commitment is made- as German philosopher Goethe wrote and I paraphrase - with commitment Providence issues forth unforeseen support.  We believe, it must happen as planned.  True?

Well, No.  In reality we commit resources, often including ourselves, with much less knowledge about the likely outcome than we often admit, but we adapt as we process feedback and steer toward value.  Initial plans are actually way over-rated.

This clarification is akin to the difference between "Ready, Aim, Fire" and "Ready, Fire, Aim".  It may sound trite, but firing first can be better than delaying to aim, and committing better than not committing.  

But that doesn't mean aiming isn't important - Aiming is continuously important but least important for the first shot.  We avert disaster with this approach by rethinking the active mitigation of risk - the continuous aiming thing.

Globalization as well as virtualization of resources, the speed of information distribution, and partial democratization of capital are some of the major forces that have shifted the way we execute plans, make commitments, and respond to change.  My opinion is that technology talent growth has actually outpaced the supply of leadership to continuously mitigate risk in the delivery of value.

We have our talent base under-employed, and leadership is needed to build value-centered cultures and processes with an understanding of business risk mitigation.

The solution is simple.   Forget about reducing the uncertainty in delivery to plan.  Focus on continuously reducing the uncertainty in delivery to value. 

Buzzword Bingo hasn't solved it:
I dislike resumes - but it helps to know some of the changes I've seen since I first got excited about automating machines.  I used to write Job Control Language and use COBOL, NDM and SAS analytics on IBM MVS mainframe systems when I was with Capgemini.  I later became a C programmer, then C++, learned an assortment of 4GL packages and added Database SQL skills to build 3 tier systems.  I worked for BEA and learned WebLogic -Java Application Server architecture and earned two certifications from SUN in Java/J2EE.  I led product direction to incorporate open-source components in bespoke solutions for clients to speed delivery of value, and guided productization by refactoring custom components and abstracting reference data.  On personal time I've hacked my way through writing programs on PC's (the most fun- an alien-attack type video game I wrote on my old Intel 80486 with direct VGA board control, in C and Assembler), MAC OS X, and Android SDK.  Parallel to this I was keeping up with the shift in SDLC methodology- (I'm a big fan of the software classics like the Mythical Man-Month or Soul of a New Machine) - from the procedural and function-point oriented structured analysis and design; to the Rational tools and their grounding of initiatives with the vision and scope stage; to OO such as Grady-Booch and the client-centered value of  Use-Case modeling; and on into our modern era with the acceptance of Agile/Scrum and it's EPIC's and User Stories as the actively managed artifacts.  My MBA degree has also framed the way I use finance concepts to calculate value.  Ok, that's my brain dump of what I've gotten out of the manuals I've been reading for 20+ years, but what are the implications?

    George Jetson, from Hanna Barbara cartoons
  • Massive, global growth in talent pool of technologists, from programming to architectural savvy
  • Architectures that allow for distributable, scaleable, and virtualized networks of systems.  Lowering the barriers to entry to technology markets
  • Anything-as-a-Service.  If it can be encapsulated and exposed, it's likely for sale or lease soon, from across the world right to your home office.

So can we talk honestly about poor outcomes? With these shifts I would think our lives would look George Jetson's by now, but they don't for many of us facing projects that are shamefully over-promised and under-delivered.  Why is the impressive personal investment of so many intelligent individuals not rewarded with a bit more of a sense of...winning...and winning as a team?  And key to it all- why do we still miss the mark too often on delivering high-value to stakeholders (project sponsors, users, customers, investor/shareholders)?

more like

Could it be as simple as not applying Continuous, Value-Centered, Risk Mitigation?  What would that look like in just a few lines:
Goal: Delivery of high-value Software within acceptable time

Process: Feature Value Assessment & Needs Prioritization (I prefer "Needs", "Backlog" is a weak term to create a sense of a forward looking, realtime process!)

Risk Mitigation:  continuous incorporation of feedback loops, multiple sources and stakeholders, agreed method of assigning financial value or balanced scorecard type value, ensure "Value over Plan" culture change - the inherent conflict that a feature value could push the plan out is dealt with via Time Value of Money (TVM) calculation.
(Warning:  Bags checked yesterday will be lost if they have no value today.)

Marvin the Martian courtesy of Hanna Barbara/ WB Cartoons
From my experience from small VC startups to some of the largest corporations, there are patterns and lessons in adjusting aim to hit value targets:
Startups:  Many create value that is quite different from the early vision, the vision that may have even brought venture capital into the firm- Twitter started as a podcasting venture, Gates was programming traffic lights as Microsoft's early raison d'ĂȘtre, almost all have big early shifts- or they die.  Create opportunities to test new value streams, fail fast, and let go of bad ideas, but be aware there can be great code (value) within an otherwise crappy idea.
Corporate Development:  I've seen shifts in needed features and their value that occur as often as weekly, meaning that even the now accepted tool for rapid delivery, the 2-week agile sprint, has a latency that introduces risk.  Users are still engaged too late and infrequently - making it certain that only through significant changes will stakeholder value emerge.  The duration and intensity of large efforts makes it difficult to retain the value knowledge of key team members who don't last the duration of the project.
Value-focused Feedback loops: from the market there are now broad, deep, and instantaneous ways to build metrics to guide the delivery of value - for example via web analytics, social media and other big data sources.  It is also much easier today to assemble the analytics tools - as a service, or via open source integration - to properly mine feedback data.  Companies are finding more internal sources of data as well - like mining call center support data for customer value insights.

The rethinking of risk means commitment to the plan is history- and commitment to value is the future.

To keep pace today we may find ourselves making commitments to half-baked ideas, we keep it from disaster by ensuring that in battles of plan versus value that begin day one, value wins (with adjustment for how delivery timeliness can be risk-weighted via application of TVM).

Nothing reduces risk like realtime responsiveness to events that shift value targets.