Q*S=R*T: Who, When and How (Part 2)

I introduced the concept of Q*S=R*T in my previous post, Q*S=R*T: A Formula for Discussing the How After the What (Part 1). The Q*S=R*T formula gives you a language to discuss how the decisions you make impact a project as a whole. In this post, I will go a little deeper and talk about who can use Q*S=R*T, when to use it, and a few supporting strategies.

Who can use Q*S=R*T?

I think Q*S=R*T is a useful concept for almost anyone who does any kind of project work. You could be a project manager, designer, developer, strategist, writer, foreman, or manager. Regardless, it is a way to frame a conversation with your colleagues and team about how you approach a project implementation. You can also sit down to start working on a task, ticket, or feature, and consider this as part of your own thought processes.

I like to keep a sticky note of the Q*S=R*T formula on my monitor to help remind me to think about how I approach certain tasks. Consider posting it on yours too!

When should you use Q*S=R*T?

In our experience, and in the way we have applied this formula, we use it under the following conditions:

Quality – There are several implementation options to consider.

Scope –  The scope is clearly defined with little to no uncertainty about what has to be delivered. If the scope is unclear, it is difficult to identify which factors are impacting it.

Resources – A single person or small team (1 – 3 people) are involved. Any more people and you start having questions over accountability. There are likely too many external factors like experience or expertise.

Time – The amount of time is bite-sized (under 15 hours). The longer the time available, the greater likelihood for quality factors to get out of hand.

When doesn’t Q*S=R*T work well?


This is a pretty simple formula and is clearly not going to work for every situation. For example, when people and operations are involved or a complex decision needs to be made, there are too many factors. You might break off small parts of a complex decision and use Q*S=R*T, but there are likely other approaches that would be more appropriate.

An example might be figuring out a change management approach when the ownership of a company moves to someone new. There are a lot of people, personalities, and situations that need to be considered when moving forward.  It is not just a question of quality of implementation or defining a schedule. In this case, the Q*S=R*T formula isn’t able to take into account all the different factors that would impact this situation.  It is not a useful tool to discuss the best way to move forward.

Illustrate the Q*S=R*T decision process with a matrix

One of the tools that we like to use to help with the Q*S=R*T decision process is a matrix. There are many different ways to make a matrix, but in this context, this is how we might do it:

  1. List each of the potential options
  2. List the pros, cons, and risks as the columns. Pros/cons are the straightforward advantages and disadvantages. The risks column is for identifying risks for you or the customer.
  3. Add the scope, resources, and time columns
  4. Fill it out by asking: What are the possible implementation options? What are the pros/cons of this option? Are there any risks? Does this implementation stay within the scope, resources, or time (yes/no/maybe)?
  5. Evaluate

Here’s an example:

  • Quality – ?
  • Scope – Display a map on a contact page
  • Resources – One front-end developer
  • Time – 1 hour

As you go through each of these options, they escalate the perceived quality of the implementation. They also break the parameters that have been given for delivery. Though the helicopter option is clearly not a good choice, you can see how the other options would not necessarily stand out as being bad for the budget.


After all this, some of you might be thinking that this is an incredible amount of time and effort to spend on implementation decisions. It is obviously not practical for every decision that needs to be made. However, the point of the exercise is not for you to make a matrix for every decision. It is to understand that every implementation is a quality decision which impacts the other three elements of the equation.

Other circumstances where Q*S=R*T might be helpful

Customer Discussions – This formula is a useful tool to bring to a customer when going through implementation approaches. It gives them options and will change how your customer thinks about change requests. It helps them understand how their requests impact the project as a whole. What if you took the example above and brought it to the customer as an example of possible ways to go forward? You might be able to convince them to add a bit more time/resources to the budget to go with the second option instead of the first. Alternately, if they are asking for aerial pictures, you have a tool to illustrate the impact of that change and help them realign their expectations.

Internal Team Discussions – When your matrix is complete, you can see the available quality levels and assess what is appropriate. This can start a discussion with your team about how to go forward. Since each option does not exist in a vacuum, you can also discuss features or options that you might want to put the extra, out of scope effort into. You can potentially reduce time or resources in other areas to make up for it.

3 strategies to support Q*S=R*T

If this is an approach that you might want to use yourself or introduce to your team, consider the following strategies to support it:


1. The people who are implementing need to be part of the estimation process. This seems obvious, but often the people who are supposed to execute on a task are set up for failure. If they didn’t help estimate it, it is reasonable that they might not be able to stay within the parameters they have been given.

2. Communicate the scope, resources, and time for each task to everyone involved. If you don’t know how much time or resources you have, how can you make educated decisions about how to go forward?

3. Have weekly time/budget check-ins with everyone. You don’t want to get to the end of the project and have no idea why you are over budget/schedule. Weekly check-ins mean you are able to talk through why decisions are being made and how they impact the rest of the project.


The larger and more complex a project is, the harder it is to estimate how much time and resources they will take to deliver. The end goal is to understand this formula and have it be part of the processes when making implementation decisions. It can help minimize the incremental budget creep that happens when decisions are being made.

For most things, you shouldn’t have to go through the effort of creating a full matrix to make a decision. Rather, you should be able to quickly discard unsuitable options. But, for things that you might be unsure of how to implement, you now have a conversation tool to help start an educated discussion with your team. It can help keep projects within respective budgets, while still delivering what you said you would.