Swimming Upstream

Swimming upstream is the tagline I choose for my blog about a year ago. I meant the term as in 'going against the flow'. The same term came up recently during a marketing discussion, but this time meaning 'to get closer to the buyer'.

I really liked it, so I thought I would share.

Cost vs Risk continued - Agile Prototyping

In my recent post Cost vs Risk, I raised the issue of risk ownership in software projects. Specifically, I talked about how iterative software process shifts risk from vendor to buyer. I also promised some thoughts on how vendor and buyer can share the risk.

Risky Business
Building software is a risky business. In modern day software development, most things change most of the time. Changes cost money. Because of this, there is always a significant risk that a software project could:

• Fail to deliver an acceptable set of features
• Suffer from quality issues
• Significantly exceed budget

Traditionally, software projects are built to spec and follow a phased approach. Requirements are gathered, a design is proposed and then the software is constructed, tested and finally delivered. The work is commonly done by a vendor at an agreed upon price. The vendor is responsible for delivering the software for the price and usually will have to accept any additional costs that they didn't plan for. The vendor owns the risk.

This building to spec approach has never dealt well with adapting to changes. In some cases the spec is well understood and does not change very often, but in lots of situations there is significant change. If the spec doesn't change a lot, the phased approach discussed is the best approach to building software, otherwise you need to take a iterative approach.

The problem is that an iterative approach is one of discovery and therefore neither a spec or a price can be agreed upon at the outset. Instead the process follows more of a 'Time and Materials' approach to cost where the buyer compensates the vendor for its time and costs as they go along. The result is that the buyer owns the risk of what is getting delivered and when.

A proposed solution - Agile Prototyping
It is possible that there are projects where an Agile Prototyping approach is an appropriate way for the buyer and the vendor to share the risk.

In this approach, the project would be split into two phases, a discovery phase that would be iterative and therefore the buyer would own the risk, and a delivery phase that would be fixed scope/price and the vendor would own the risk.

The discovery phase would consist of the vendor and the buyer working together very closely. Resources from the vendor side would be exceptional at crossing the technology business divide as well as excellent programmers, capable doing magic things with software in very little time. The deliverable of the discovery phase is a working prototype that delves into each functional aspect of the system without fully fleshing it out. It would pay no attention to IT issues such as scalability or performance. In essence, at the end of the discovery phase, a executable spec is delivered that is of sufficient detail so that 'fleshing it out' and delivering it is something that can be estimated and sold at a fix cost.

In the delivery stage, the vendor assumes the risk, but also is freed from the constraints of working with the customer. The vendor is free to deliver the software in the most economic way it can safely do it at the price quoted.

The key assumption that is being made with this proposed project structure is that the majority of change in some software projects, is not really change at all, it is discovery.

For projects where the primary change component is discovery, the benefits of this structure are as follows.

1. It enables the buyer and the vendor to share the risk and therefore makes it much more attractive to both parties.
2. By separating the clients involvement into the discovery phase, we focus them on the decisions that they need to make and avoid asking them to make decisions that generally they don't want to make (such has mundane UI details).
3. Free the vendor to deliver the project in the best way that they can.
   
4. Concentrate skills of workers into the phases where they can have the best impact

The unknowns/negatives of the approach are.

1. How much of the cost of the project can be moved into the discovery phase?
   
2. The risk is shared, but does the overall cost of the project go up or down?
   
3. How much of the prototype is reusable?
   
4. Do modern technologies such as rails enable fast prototyping?
5. How easy is it to find people who can 'cross the technology business divide' and be excellent programmers?

What do you think? Tell me about your experiences and if you know of projects that could have benefitted from this approach? Have you experienced tense relationships with buyers because they assume all the risk?

Opportunity Cost

In our work at Obtiva, I increasingly find my self thinking in terms opportunity cost. Simply put, opportunity cost is the benefits that you could have received by taking an alternative action.

Wikipedia describes it as

Opportunity cost, or economic cost,is the cost of something in terms of an opportunity forgone (and the benefits which could be received from that opportunity), or the most valuable forgone alternative (or highest-valued option forgone), i.e. the second best alternative.

In finance, opportunity cost is often considered when taking a position or making an investment. The opportunity cost is considered to be the difference in return between a risk free investment such as a government bond and the alternative investment considered, such as a stock. A guaranteed return (roughly 4% in todays markets) can be expected from a government bond, so each investment should be considered with this alternative in mind.

At Obtiva, we are fortunate to have lots of opportunity at the moment so considering alternatives is important. When considering alternatives, it takes some creative thinking to see all of the possibilities.

For example, opportunity A might generate more revenue in the near term than opportunity B, but opportunity B might be breaking into a new market and therefore in the future may be more desirable. Only by carefully looking at the alternatives can a proper assessment be made.

Cost vs Risk

There is a subtle difference between Risk and Cost that often gets over looked. The reason for this is that the cost of something usually contains a risk component. For example, when someone lends you money, they expect you to pay it back with interest. Part of the interest is to cover the risk of you not paying back the money, in affect they have put a price (or a cost) on the risk. The subtle difference between this cost of risk and actual risk is that this price is just an estimate. The risky situation may or may not happen in the future.

A quick anecdote:
I once had a conversation with a brilliant financial analyst regarding Fixed and Floating rate Mortgages. I was pleased with a realization that I had come to after looking at the two types. The realization was that the *overall cost* of a Fixed vs a Floating mortgage was comparable. Sellers of mortgages are so good at pricing a fixed rate mortgage, that the overall difference in cost between a fixed and a floating rate would be minimal.

The response from the brilliant financial mind was simply 'Yes, but the Risk is not the same'.

Duh, I hadn't been thinking about that. To me, the 'Risk' was choosing the higher priced mortgage, not the possibility that a floating rate mortgage could move outside the bounds of what was expected. It seems obvious now.

This brings me to the topic of this post. Cost vs Risk in Software Contracts.

Software Contracts

Recently I have been about thinking the Cost vs the Risk of Fixed Price and Time and Material contracts. These contracts are another example where cost can often work out to be the same (as vendors get better at estimating and pricing Fixed Price contracts the price will converge) but the risk is different.

Because software is a risky and unpredictable business, buyers naturally prefer Fixed Price contracts. Generally they cost about the same, but the vendor owns the risk instead of the buyer. However, the software world is starting to understand what those in the Agile community have known for a long time, that an iterative and adapting software process is ultimately the better way to build software. The problem is, that by definition, an iterating and adapting project can not be Fixed Price and therefore the buyer must absorb the risk.

Kent Beck and Dave Cleal wrote a paper called Optional Scope Contracts that proposes a fixed cost, fixed time frame, floating scope approach. The basis of the proposal is that with a Fixed Price (ie Fixed Scope) contract the first thing to be compromised is quality and that just transfers the risk and in some ways makes it even more unpredictable.

This is certainly a move in the right direction. It recognizes the need for flexibility. It says it how it is. Unfortunately, it still has the buyer assuming the risk.

Check back here soon for a continuation on the theme including ways for the vendor and the buyer to share the risk.