Satter Ramblings

Microsoft Product Blogs

Have you ever wonder how to keep up with the flood of information coming from Microsoft? It turns out that there are lots of resources provided by Microsoft. And a good place to look turns out to be a blog, specifically BlogMS! BlogMS was started by Daniel Goodman (a Sr. Technical Account Manager) in his words he started BlogMS in May 2008 in response to customers who wanted to feel closer to Microsoft in order to keep up-to-date with what's going on across Microsoft including the products groups. Think of this website as connecting the dots!

Project Management

Recently I have been reading general business books. I wanted to see if business project management differed from project management books for computer projects.

Agile might not be so agile.

Here is an interesting articlce about Agile programming, Agile programming has fallen short, conference told | InfoWorld | News | 2006-03-13 | By Paul Krill.

Tools of the Trade (Cost Benefit Analysis)

Last week I start by looking at what tools exist for making decisions. There are many tools for making decisions in the business world including decision trees, grid analysis, paired comparison, cost benefit analysis and Pareto Analysis (80/20 rule) to name a few (see Mind Tools additional tools). Other useful tools from the software world are best practices and design patterns. I then expanded upon paired comparision.

In this article I will look at cost benefit analysis.

Cost Benefit Analysis

cost benefit analysis or return on investment can be a very useful tool. This is the traditional decision on whether to start a project. You simply take the total cost of a project divide by the total financial payback. This gives you the payback time.

It can also be used in other ways especially by product companies. By targeting certain the return on investment against a benchmark for example the S&P, one can calculate how much revenue a product must sale at a minimum. For example, if I had a $100,000 I can invest it and historic returns should be around $11,000. Therefore any product development expenditure must return more than investment in various financial instruments.

This approach has several benefits. The first is that success of a product can be measured by its return on investment (ROI). This will assist management in allocating resources to various product developments efforts. Secondly, it can be used to evaluate whether to build, buy, or acquire an existing product. Third, it can establish clear gross margin goals and thus revenue targets that must be meet by a product or product line. Fourth pricing models can be more accurately created. If a product or product line cannot be seen as reaching its revenue goal and has no strategic value then an alternative can be evaluated for example:

• Can the product be built at a lower investment rate that can fulfill the revenue requirements?
• Can an acquisition solve both the revenue and cost equation?
• Is there another organization willing to invest money in the project and thus lower the cost?
• Is there another solution?

How can a product company formulate a required ROI that every product must meet at a minimum? The percentage needs to account:

• A particular benchmark such as the historical returns of the S&P
• Risk of development
• The lack of liquidity of product development i.e. it is harder to sell a non-publicly traded company or piece of a company than shares in publicly trade financial instruments like stocks.
• Additional overhead and sales cost to be covered by the product line
• Age and capability of the company.

This means our return must included the return of the S&P which is around 11%, and pay back all the investment cost of development over a set time period. In addition, the product has to generate revenue to cover additional overhead and sales. I use a 10 year time horizon. These means that over 10 years the software cost of the first year will be paid plus additional return greater than the S&P. Older companies can use higher returns since they can leverage their market power to increase sales.

Based on these criteria the ROI for a startup might be at least 50% per year. This is based on the traditional timeline for a startup, typically 5 years to break even. So in the first 5 years of a product the first year of development should be paid and at 10 years the first year of development should have been completely phased out. Or put another way

• 10% principal payback per year over 10 years for development
• 25% for overhead and sales cost
• 15% return on top of the principal as interest

At first glance it may seem ludicrous to assume the product in its current form will last 10 years, however, successful products like Office, Quicken, and SAP still have functionality that existed in the first version. And in the corporate world I and I am sure you have seen programs that were written several decades ago still lingering around both homegrown and commercially available software. Finally, if you are building a company that will last then a long payback time forces people to think and invest in the long term rather than short term thinking.

How can this technique help? It gives me two things. First I can project minimum revenue for each year. Secondly I can set minimum pricing.

Here is a real life example. InQPro is working with a startup software company and a venture capital investor. The company is looking at a hard dollar investment in product development of around $500,000 over the next year and a growth of 25% for the second year and 10% for subsequent years. Using this formula the marketing group needs to see if they can realistically sell the required revenue each year. If this number can not be met then either the cost is too high or the market is too small to support the company. In addition, more development dollars will be spent in the year and subsequent years thus increase the minimum required revenue goal. This creates additional revenue drivers.

If total development cost is US$500,000 in the first year that investment must make at a minimum US$250,000 per year for the next ten years. Additional investment in development adds additional revenue demands so if the company were to last 5 years then the company needs to deliver almost US$2 million in revenue at a cost of $1 million additional development costs. And in year 9 revenue would be US$4.5 million at a cost of US$1.5 million. It is important to note that revenue growth is outpacing development cost growth which leads to the cost of development as a percentage of revenue to shrink each year. Thus early years the company is losing money while later years are leveraging earlier development to make more revenue.

Investment per year	Year 1	Year 2	Year 3	Year 4	Year 5	Year 6	Year 7	Year 8	Year 9	Year 10
$500,000	$250,000	$250,000	$250,000	$250,000	$250,000	$250,000	$250,000	$250,000	$250,000	$250,000
$750,000		$375,000	$375,000	$375,000	$375,000	$375,000	$375,000	$375,000	$375,000	$375,000
$1,328,671								$664,335	$664,335	$664,335
$1,461,538									$730,769	$730,769
$1,607,632										$803,846
Total Revenue	$250,00	$250,00	$250,00	$250,00	$250,00	$250,00	$250,00	$250,00	$250,00	$250,00

In 2002 a study by National Association of Software & Service Companies, Nasscom, found in a detailed analysis of 249 mid-sized ISVs with revenues less than US$100 million the following. The average size of the company was US$ 39 million, and the net margin was -26%. These companies jointly had revenues of US$9.7 billion. They spent US$12.2 billion losing US$2.5 billion. They would have been better off investing the $12.2 billion in the stock marketing. At the end of the year they would have had around US$13 billion or a gain of around US$800 million.

Tools of the Trade (Paired Decisions)

Let's start by looking at what tools exist for making decisions. There are many tools for making decisions in the business world including decision trees, grid analysis, paired comparison, cost benefit analysis and Pareto Analysis (80/20 rule) to name a few (see Mind Tools additional tools). Other useful tools from the software world are best practices and design patterns.

Product Decisions

This article takes a look at decision making and in particular how to make better decisions especially in choosing whether to write a new software product, buy some software or not implement a software solution at all.

In writing this, I came to a realization. That software whether written by one person or thousands is the culmination of decisions. As the saying goes your life is the sum of your decisions so is software. Intuitively people have been striving to create tools and frameworks for making decisions for example best practices, design patterns, and software methodologies. Software methodologies at there core fulfill some or all of the following:

• The ability to give decision makers a strategy for making optimal decisions for that software
• Tools for decision support
• A list or road map of major decisions to be made i.e. architecture, requirements, testing strategies, tools to be used
• The ability to detect and correct suboptimal and non-optimal decisions
• Mitigate the risk from suboptimal and non-optimal decisions
• Communicate the decisions that have already been made, what decisions need to be made, and how to chose the optimal decisions
• Measure the progress and the chance of success

However, in all the reading on the field that I have done over the decades, I have found few articles that answer these questions:

• How do you make decisions?
• How can I increase my ability to make good decisions?
• Can a framework for making software decisions be formulated?
• Can you measure the quality of a decision?
• What is an optimal decision?
• And most important how do you string together optimal decisions to have a successful software product or application delivered in a repeat fashion?

This article explores these questions and the questions that come out of that exploration.

What is a decion?

Let's start with the easy stuff the mechanics of a decision. The Merriam-Webster definition of a decision:

1 a : the act or process of deciding b : a determination arrived at after consideration : CONCLUSION 2 : a report of a conclusion 3 : promptness and firmness in deciding : DETERMINATION

Not a lot of help but essentially a decision is the result of making a choice. For example, choosing between programming in C# or VB. Using a “for” rather than a “while” loop. Both have choices to be made. And those choices bring consequences both intended and unintended. Ultimately, one or more people make a single choice and hence a decision.

Another aspect of decisions is that there are levels of importance and impact. For example, while coding, experienced programmers think very little about each line of code. In fact you could say that it these small decisions are reflexive decision. We spend more time with algorithm design and class design. Overall architecture and strategy require more attention and consideration. As you get up further in the development hierarchy your decisions have more impact as do earlier decisions like architecture, tool, design, and process decisions.

The Effects of Decisions

Decisions not only have impact the moment they are made but ripple out. And multiple decisions have incremental or even expontential impact to a project. Just as some people would say that you are the sum of your choices so are software projects and applications. For example, in the 1990's people at Microsoft made decisions based on making the user experience easier. The intended consequence was rapid adoption of Windows and Office. The unintended consequence was a platform that was insecure.

Here is another example. I worked on a project which was the fifth attempt to replace an existing corporate application. Interestingly enough the fourth attempt was about 80% complete, however, it was decided to rewrite the whole application. Why? The cumulative decisions had negative impacts on performance, maintainability, and extensibility of the application. Was this just the culmination of bad decisions? If you look at each decision in isolation I would say that each individual decision on the whole was a good decision. To be clear looking back some where bad decision but at the time and with the available information the decision was a reasonable choice. Just like Microsoft's choice to focus on easy of use and integration. Looking back it looks like a bad decision however at the time it served its purpose the expansion of the Windows and Office platform in the market place.

At every level, developers, managers, and domain experts made good decisions at the time in writing the fourth version. And yes they made some bad decisions as well but no one decision stands out as just being glaringly obviously wrong. Rather it is my belief that the project lacked a framework for making decisions. This is I believe a critical point. Decisions in a vacuum become a crap shoot for the overall cumulative effect and without a framework to guide the decision making process, what is a good decision on one project can be a bad decision on another.

While we are on the topic project failure it is interesting to note that project failure rates have declined in 10 years (see Chaos Reports). The percentage of projects that failed or had some significant issues in 1994 was 84% and in 2004 it was 71%, a change of 6% per year. Not bad until you find out that a majority of the change came in a two year period from 1994 – 1996. So the real rate of return in the last eight years is less than 1%! I do not want to down play the complexity of software however if our business leaders failed this much the economy would be much worse off. If business units can make cumulative decisions that improve productivity, revenue growth, and profits; it might be worth looking at what they are doing right i.e. decision making which leads us directly into my next two questions:

• How can I increase my ability to make good decisions?
• Can a framework for making software decisions be formulated?

I will start to cover those in my next posting.