I have been doing some business analyst training recently and I spoke about a “trade-off matrix” a couple of times. A couple of people have asked for a good link to explain what one is and why they are so cool. So I looked on the web and couldn’t find anything decent enough to send through.

So I thought I would describe what a trade-off matrix is here. I will also briefly mention why they are useful and then mention a couple of variations that people might not have heard of.

So – what is a trade-off matrix?

Just as it says – a trade-off matrix is a matrix (table) that shows trade-offs.

One of the most common uses for a trade-off matrix is to show different non-functional requirements and the areas where a trade-off might have to be made between some of them. (Hmm – should I say non-functional requirements or quality of service? Either way I mean quality attributes of a system).

Let’s assume that we are producing a new mobile application to provide students with access to training and certification while on the move. We have some features like login, book a training course, take a training course and sit a test.

But in addition to features there are a lot of expectations that our students will make about the quality of our application. For example they might want their test results to be accurate, they might want their personal details to be secure and (if we charge for some courses) their payment details to be extremely secure. They might also want usability, accessibility and a bunch of other things that are becoming more important that the features now days.

But there are some challenges for us. Security and usability are both important but there is potentially a trade-off to be made here. It would be convenient to be able to just pick up my device and access my course with no password … and it would be secure to require dual factor authentication is strong password protection that requires a password change every week. But these solutions inhibit the other aspect of quality.

A trade-off matrix helps us identify and communicate these trade-offs so that we can deal with them intelligently For example:

 

Reading the table left to right I can see that there is a negative relationship (a trade-off) between security and usability. There is another trade-off between security and simplicity. I have also claimed that there is a positive link between usability and data accuracy – presumably usable systems are less error prone.

This can be useful in itself but it is even better if I can use this to reduce trade-offs. To do this you simply find a trade-off (say security/usability) and ask “what can we do to boost BOTH security AND usability at the same time”.

Often, people see a trade-off and simplify their thinking to “which do you want, security or usability?” Of course, the answer is that I want both. So then we start analysing all the trade-offs we have to make in order to not get either of them (or at best to get some of both of them).

It is possible that I will have to make a trade-off, but I think you will be surprised how often you can be innovative if you start with “how can we maximise A and B?”

So let’s see – how can I have both good security and good usability? Well – finger print ID might be good or I might have a Facebook login to save having to remember passwords. Hopefully we can generate several options to help.

Once we have been through the brainstorming stage of “what can we do to maximise BOTH at once” then we might still find we need to make a trade-off. But at least we can now be clear … we will put the pressure on someone to tell us either

• I am willing to trade security of usability; or
• One of these to is a constraint – lock in a set level of security and then make it as usable as possible within that constraint.

Trade-off matrix transformed into a conflict management tool – the options generator

But the trade-off matrix is not just used for the quality components of a product, it can be used for anything. For example, the same humble tool is called an options generator in conflict management. For example let’s assume that I am the IT manager and you are the business manager. You have been told that you need a 10% cut across the board, that you need to deliver a product early and that you need to address a compliance issue. Your costs are dependent on me so you want me to take a 10% cut in the charges I pass onto you, but our CEO has been harassing me lately too. I need to improve my disaster recovery capability and I have committed to improve the sagging morale in my team.

Now we don’t have the same things in our column headers as we have in our row headers, but the process works the same way.

 

Things look a bit dire now – we are in conflict all over the place. Indeed there is a risk that we will jump from topic to topic arguing away. So now we agree to have one argument at a time (how can we improve DR and cut costs at the same time?). There might actually be a way if we can retire some old servers or maybe I can consolidate the applications we use in an area … cutting both DR complexity and cost.

Of course we might fail to find a solution. But at least we can escalate a common message – the organisation needs to make a clear trade-off in order to gain one of the two benefits. Often if we found some common ground, then at least we can make a more acceptable decision about the rest.

Delivering your compliance project means pushing some of my staff to work late and delivering your other project means the same thing. But is there a way we can deliver the project early AND improve morale? Maybe we can cut the scope people don’t believe in or maybe we can link early delivery to some team reward. Similarly we might find that we can make the impact of the compliance breach clear to the team, drop the early delivery of the other project altogether and improve my teams morale. Of course the tool does not guarantee that we will collaborate and find an innovative solution – it just improves our chances.

Trade-off matrix in reverse – the options generator again

Another use of the options generator is to generate options from our existing capabilities and needs. For example, let’s say that

• You have the following needs – need faster delivery of services; need career progression for the team.
• You have the following strengths according to your recent SWOT analysis – Strong accounting skills; young eager team
• You have the following issue that your highlighted in your SWOT analysis – seasonal work fluctuations with end of year and quarterly reporting being the busiest
• I have the following needs – more testers
• I have the following strengths – good developers in mobile
• I have the following issues – too many projects at one time

Let’s create our trade-off/options generator again. But this time we will put ideas in the trade-off boxes instead of arrows:

 

I don’t know if any of the opportunities will actually pan out – they are options to consider. But rather than just rejecting them out of hand, we should try a little harder.

The next step is to graph our ideas on two axis – difficulty and value. For the high difficulty/low value ideas, just kill them now. For the easy/high value ideas just do them. For the high difficulty/high value – consider them properly. For the others just decide to do them or not.

Oh and if you want more options – when you see an idea is difficult, ask yourselves “How can we get the same benefit without the difficulty”.

Trade-off matrix in disguise as a things that matter table

A “things that matter table” is just a table showing the factors that will impact the ability to deliver a new feature or the ability to gain value from it. For example, let’s look at our original product idea at the top of this article:

 

This time my table only has two downward arrows. It turns out that I currently partner with a company who provide online training to my internal teams and to some of my customers. The downward arrow suggests that the partner will be unhappy if and when I deploy these features. How can I improve my relationship with the partner AND deploy these features? Maybe we can offer their courses or maybe they can provide the functionality … or maybe there is a trade-off to manage. I better start managing my communications with them.

The H, M, L means that the feature at the top will require work in the area on the left – H for high effort, M for medium effort and L for low effort.

This tool is also used to compare what my customers want and the features that deliver them … and sometimes we add how our competitors rate in the area. The matrix now looks like this:

 

So here we can see which features of our app actually matter to users – not because the feature matters but because the feature supports (or inhibits) the things they want to use our app for.

This table is a simple version of the House of Quality from the old school QFD (Quality Function Deployment) approach to product development. Nobody seems to remember it anymore but I have fond memories of complex trade-off matrices and challenging conversations about how to build Quality AND (insert anything) rather than trading quality off. I will leave you to do your own research on these “Godzilla scale trade-off matrices”. http://en.wikipedia.org/wiki/Quality_function_deployment