Optimizing Your Delivery Approach Based on Market Risk

Very often I get into conversations with clients and colleagues around how technology X or approach X is going to make product delivery both faster and cheaper at the same time. I'm sure I'm not the only person who's read a marketing blurb around how SOA is going to both increase agility and reduce cost. The major issue I have with these statements is that creating a delivery system of work that is optimized towards cost tends to look very different from a system of work that is optimized towards speed. Many of my clients want help in optimizing both, an interesting exercise that I have them do is determine the kind of business that their IT organization is trying to support. One way to categorize an organizations delivery objectives is to use an innovation scale, where True Innovator is at the top of the scale, and delivering Commodities/Table Stakes requirements is at the bottom of the scale.

While only a small number of organizations can be considered True Innovators, many find themselves in the First Mover or Fast Follower space. When supporting this kind of business, Cost Of Delay is considered to be relatively high, when compared to the Cost of the Work. In other words it makes more sense to increase capacity in order to deliver faster. People in the lean /kanban space will recognize increasing capacity as another way of limiting WIP to low levels. Lower WIP implies more collaboration, a more streamlined processes and an agile approach. Handling the higher variability in this domain also requires less attention to centralized governance and standardized processes. This approach has the effect of delivering much faster but causes cost to go up.

Other organizations support requirements for much more stable business problem domains, and are often concerned with delivering cheaper, cutting costs, and providing table stake type requirements to their customers. In this scenario Cost of Delay is much lower relative to the Cost of the Work. In this case utilization should be much higher, and spare capacity should be much lower. Highly specialized resources, standardized processes, and economies of scale are used to drive down costs. Of course this approach causes delivery cycle times to take longer. Highly centralized governance required for standardized approaches slows things down, so do all the hand also required because of specialized resources.

One interesting note is that most clients that I've worked with make the error of optimizing towards trying to cut costs thinking that this will also allow them to deliver faster. Most people I have worked with also underestimate the inherent variability in the problem space that they are working, using a new technology to solve a commodity business problem also counts as innovative use, and the laws of using lower WIP apply.

It's interesting to note that highly valuable, innovative, first market features fall squarely in the domain of agile teams, working in small increments with spare capacity to manage variability in the problem space. Commodity problems using commodity technologies fall more comfortably in the waterfall style approach. That being said, IMHO I don't believe that even package installation (e.g. SAP) with a moderate amount of vanilla configuration falls into this commodity space. If there is a requirement to contextualize technology to a customer's environment then I don't believe the product should be treated as a commodity, and some element of lowering WIP, and leveraging feedback should apply.