I certainly agree that as a general rule having customer focused goals are prefereable to internal goals. After all, our customers provide our revenue, which is like food or water to a business.

But things are always more complex then they seem!

What happens if the software manager is under pressure from his boss to improve quality, or what if the software project team will get bonuses if their achieve certain quality metrics.

People behave in certain ways for lots of complex reasons. That’s because everybody has their own “value model” which establishes their priorities and guides their behavior.

One of my favorite documented examples of this is in Chapter 2 of the book Freakonomics, by Levitt and Dubner. After examining thousands of real estate deals in metropolitan Chicago, they found that real estate agents who represented themselves kept properties on the market for an average of 7 days longer and sold homes for about $10,000 more than when ther represented another client.

Hmmm, you’d think that the real estate agent was working in the best interests of their client, right? Problem is, their client’s interest has two driving variables: time to sell and sales price.

In this case, when the real estate agent sells their own propery, the extra $10,000 goes into their own pocket. This is enough to justify waiting a week for a better deal.

However, when they represent a client, the 6% commission on the $10,000 price difference is $600. When split 50-50 with the buyer’s agent, the difference is $300. Given this, which real estate agent accepts the risk of losing the buyer by stalling, and tries to hold out for a better sale price?

Cheers,
Charlie

I think you make a very nice point to show that the end goals are not needed to be aligned, or perhaps better said the same, when talking about efficiency and effectiveness, at least if I grasp fully your definitions. From some perspective this unalignement can be obvious and needed, still I have the idea that being more customer-oriented and for example less solution-oriented is more generally suited, ofcourse for your customer but also for the software company. The customer naturally has his perspective on these quality aspects and so the software company.

If the software company was customer-oriented and fully aligned with the goals of the customer I still have the impression that the relevance of efficiency would still come after the effectiveness aspects. If the approach the software company would use, reduces most of the big crashes and thereby provide a higher availability, which is for example an important business goal of the customer, the approach is effective for the customer. If the software company helps achieving this goal fast, it is an efficient approach for the customer. A part of the customers main goal is reached, namely high availability. The approach of the software company looks thereby to the customer primarily effecitive and secondary efficient and I think the software company can also gain a lot by using this perspective.

Ofcourse like you say (if I understand well) perspective (and/or context) says it all. Your definitions are more general perhaps than my customer-oriented view. In a way I think customer orientation is the best way for whatever outcome of the business. Agility helps in this area too. We do our job to satisfy our customers, at least I try. But this is another discussion, but I think you are right with your more general definition. But if I may ask, should customer orientation than not be the main orientation of a software company?

Greetings

I think that efficiency is a measure of effort required to achieve a goal that is important to the subject. While effectiveness is a measure of utility, seen from the perspective of whomever the effort is intended to satisfy.

For example, suppose a software project wants to achieve very high quality and measures this by defects (weighted by severity) per thousand lines of code.

One approach the team takes is to fix all of the easy, low severity bugs. If viewed (myopically) by engineering management, this project could be the model of efficiency. The bug elimination rate is the highest in the company.

However, if we look at effectivenss from the perspective of the customers of this software system, this low-severity bug jihad is not very effective. The relatively small number of high-severity bugs still cause frequent crashes and data corruption at hundreds or thousands of customer sites daily.

So, this is a typical value modelng scenario, the things one chooses to measure and the value they place on various measurements is subjective.

Engineering management measures bug removal effectiveness strictly in terms of quantity, severity, and effort, and on those measures the project team appears to be extremely effective.

Customers measure bug removal effectivenss based on the amount of damage the defects cause, and how quickly the bad ones are eliminated. Using these measures, the project team is relatively ineffective.

Cheers,
Charlie Alfred

Thanks for the response.

I have to say that in your example you are measuring efficiency with an intermediate state and only effectiveness with your end target. In you definitions:

- Efficiency means that you get where you are going with little waste.
- Effectiveness means that you found the right place to go.

you also measure with your end goal. Although you are going to the restaurant you talk about it to be efficiently but was this really where you need to be? No, so it is not effective and first it looks efficient, but it is not where you need to be so it was a waste of your time and not efficient. Your example measures efficiency and effectiveness with different goals. Measuring these qualities can only be done/or being relevant when it is done against the same end goal.

You initially don’t have to measure efficiency when you are at the restaurant. You have to first evaluate the effectiveness. If this turns out to be ok then it is relevant to take a look to the efficiency part else talking about it and saying it is efficient is not relevant. Like you say first tackle the effectiveness than efficiency.

You say “Once you can always find the right target, then you worry about improving your process to be more efficient. “.
In this phrase you also state (implicate) that when you talk about something to be efficient it has to be first already effective.

Grts,

You can very efficiently go to the wrong place. For example, say you are going to dinner with friends. You know a shortcut to the restaurant, and get there in record time, hitting all the lights. You were very efficient. Unfortunately, it is the wrong restaurant. You were not effective.

The main purpose of agility is to have feedback loops to improve your aim at the target, that is, to figure out how to be effective. The act of being agile may include many false starts and turns as you go. Generally speaking, it does not try to find the fastest way to the correct target, which would be efficient. It is only trying to find the right target eventually.

Once you can always find the right target, then you worry about improving your process to be more efficient. That’s the point of my blog. Unfortunately, many businesses focus on efficiencies before they are effective. By doing this they make it very hard to be effective, and wind up doing the wrong thing very efficiently time after time.

Just a quick response… Dan

Over the next few weeks we will be launching a blog where we hope to demonstrate some of the cool features of the product, as you point out it makes integration with Ax super easy.

Some features of the provider; Follows the Linq to SQL model, exposure of the Dynamics dictionary via .Net objects, VS ‘AxMetal’ Addin for generating the data contexts, Create, Update and Delete support for single and multiple row instances, full support of Ax transactions and of course retrieving data via the Linq syntax.

If anyone has any questions about the provider then please feel free to contact me.

Thanks once again.
Jonathan