Determining success in software product development

My blogging has slowed to a crawl in the past few months. This is in large part because my group (SAP Governance, Risk and Compliance) has been on the verge of releasing two new versions of its flagship products Access Control and Process Control. Like a marathon, it’s that last mile that hurts the most.

During this past year and especially during the past few months, I’ve spent a lot of time thinking about what defines success when one delivers software products. It’s very difficult to know when to say “job well done” and I think many experienced software executives still make this call incorrectly.

False Measures of Success

If you work in software, you can understand why this assessment is hard. Software development is a tricky activity to measure, and the measurements you can make are very context dependent. Thus results are typically useless when comparing one product or release to another.

For example, you cannot say you have been successful if you “delivered the product on time.” After all it is easy to deliver a product on time if you cut back on scope or skimp on quality. This basic product delivery loophole is a byproduct of what project managers refer to as the “iron triangle” of scope, cost and quality. To move one variable up you must decrease the others and these relationships are for the most part fixed.

You also cannot say you are successful if you “delivered the product on time, on scope on quality.” While this sounds impressive on the surface, it is really more a function of good expectation management. Time, scope and quality are things you set targets for (i.e. fixed values). Whether you arrive ahead of or behind a target value has a lot to do with the target itself. Delivering on time, on scope, on quality is more often the result of a successful negotiation on the part of the project manager.

Any Hope to Judge Success?

I’ve come to understand that there are actually two triangles and, given the right timeframe, neither one of them is iron.

Let us call one the “execution triangle.” This is essentially the same stuff as the iron triangle: scope, time/resources, and quality. In software, this triangle is truly iron for short periods of time (e.g. 3-12 months), but you can push and pull at it when you look beyond that time horizon as you have more freedom to change processes, practices and technologies.

The other more strategic triangle is the “context triangle.” It is comprised of change, waste and innovation.

Change – how rapidly is the context changing while the product is being built? If you decide to simultaneously change the architecture, the people, the technology and the requirements, the size of the execution triangle will get very, very small.

People – how many good people do you have on the team? Product managers that write first rate requirements? Engineers with years of experience with the tools and technology? Architects that are not astronauts? If you want to accept more change with the same level of waste, you need better people on the team.

Waste – What percentage of the time and money you spent on release was put to productive use (i.e. working code that someone wants) and how much was lost to confusion and dead ends? If you want more change with the same people who built the last release, you must accept more waste.

The relationships between the elements of the context triangle are also fixed (e.g. the same release with a higher rate of change will result in greater waste). In addition, the context triangle drives the size of the execution triangle. If you have great people, low waste and a low rate of change, you can deliver some 5-10 more functionality with the same amount of time and same level quality as you otherwise could have.

Many people, executives in particular, are willfully blind to the context triangle. They do not want to believe it exists because it takes away strategic choices. To understand the context triangle is to understand for example that one cannot enter a new market with a new product on a new technology platform with a newly hired team.


So What’s Your Point?

Like most things in business, it is important to distinguish between lucky and good, circumstance and success, however tricky it may be. And so, true success in software development is the execution you achieve given your context, because the context is almost never under your control. Change, waste and innovation are the cards you are dealt and how much scope and quality you derive from these circumstances are how you played them.

P.S.

If you're in the market, please take the time to check out the newest releases of SAP GRC Process Control and Access Control. They’re both excellent. I should know :-)