Q*S=R*T: The Formula for Evaluating the “How” of a Project, After the “What” (Part 1)
After running a software company for the last seven years, I am no stranger to the intricacies of project management. Keeping projects on time, on budget and done well is a magical and challenging prospect. There are a million different variables to juggle at any given time, many of which we have no control over. Project management challenges are, of course, not limited to the software industry and can be applied across any project-based industry from construction to marketing to government, etc. We all strive to achieve the trifecta but the reality, and how it is often presented to our customers, is the triangle of Good/Fast/Cheap where they can only pick two. While this is a good conversation for setting expectations it doesn’t provide you or your team a formula for having a discussion about the best way to approach certain tasks.
We were introduced to the following approach at a presentation by Dr. Ray Muzyka (who is also one of my wonderful mentors). It breaks the discussion about how to manage a project into an equation involving four elements, instead of just the three above.
Quality * Scope = Resources * Time
Q*S = R*T
The idea is that if you increase an element on one side of the equation, then you must also increase an element on the other.
In the example that Ray described to us, he was applying the concept to video game graphic design. He described three quality levels as gold, silver, and bronze, and which one you chose reflected the complexity required for the design. For example, if you were trying to decide how much time and effort you were going to put into the design textures, you might have the following parameters:
- Gold – The textures are immediately and highly visible in the foreground of the game, and therefore need to be very detailed.
- Silver – The textures are less obvious but still in the foreground and therefore need less detail but still reasonable attention.
- Bronze – The textures are far in the background and therefore can be less sharp and require less detail.
When Ray spoke about this in relation to his business, it really clicked with us and made us think about how we approach our software development projects. We applied it to our business and defined each element as follows:
- Quality: What implementation should I use?
- Scope: What did we agree to deliver?
- Resources: Who is working on it and what tools do they need to deliver?
- Time: How much time do we have and what is the schedule we agreed to?
Other examples of Q*S = R*T
Here are a few more examples:
- You are a web developer and you have been told that you had 10 products to add to an e-commerce website. Suddenly the customer comes back and says there are instead 100 products, but they want it delivered in the same amount of time. The scope has just increased significantly so you could add more people (resources) to the project to keep to the schedule.
- You are an interior designer and you are doing a review with a customer and originally budgeted for one round of reviews. During the review meeting, the client communicates a change in the dimensions of the bathroom floor plan due to the way the pipes are situated. You will have to do another round of revisions and an additional review meeting to ensure the changes are captured properly. The scope has changed so you will need to adjust your resources and time appropriately.
Quality is the How
A challenge that our company battles is that scope, resources and time are pre-determined as part of a proposal. They are the WHAT part of a project discussion. In the proposal we decide:
- What is the scope of work?
- What resources will work on it?
- What is the time/schedule?
The quality discussion is about HOW you are going to implement, given the other parameters. This means that quality is the only variable that we can control after quoting on a project. This also means that quality decisions that our team members are making are then also a part of how projects budgets might get overrun.
Changing Quality ≠ Bad Work
Let me clarify that in our interpretation of this formula changing quality is not cutting corners, doing shoddy work, or creating technical debt. There are multiple ways of solving a problem or implementing a feature and quality is what method you choose. You need to use your judgment as an expert to decide what quality level is the appropriate solution or implementation. In the case of software development, you still need to ensure that you are providing a good user experience that meets the scope of the resources and time that have already been determined.
Let’s walk through an example:
- Quality: ?
- Scope: Write a marketing plan
- Resources: One Marketing Strategist
- Time: 5 hours
If the Marketing Strategist is given these parameters, they need to think about the quality level they can produce. Things like:
- How long will the report be? – 2-3 pages.
- How much depth do they go into? – High level.
- Are they having the document custom designed? – Likely to use a template instead.
- How much time can they spend interviewing stakeholders? – Depending on the number they want to include, 10 or 15-minute phone calls.
- How much time can they spend on research of the customer’s industry? 1-1.5 hours.
Given this amount of time, the Marketing Strategist will only be able to produce a certain quality level. What happens if the time parameter changes to 15 hours? Suddenly the decisions the Marketing Strategist can make will be very different:
- How long will the report be? – 10-15 pages.
- How much depth do they go into? – Mid-level.
- Are they having the document custom designed? – Ask the team designer to put together a cover page and some small graphics.
- How much time can they spend interviewing stakeholders? – 30-minute phone calls.
- How much time can they spend on research of the customer’s industry? 3-5 hours.
The marketing plan will be produced regardless of the amount of time provided, but you can see how the quality of the plan would change if the Marketing Strategist was given more time.
Managing budgets around quality
What if the marketing strategist was given 5 hours but took 15 to complete it? This is where we see a lot of challenges in managing budgets for our projects. We often have team members who want to do a really great job on something or try something new and exciting, and they take longer than the budget they were given. They might have produced a higher quality deliverable….but we are not going to get paid for that time. The discussion ends up being about understanding that by making the decision to go beyond the budget, they put us in a tricky situation with the customer because we probably can’t ask for more money, and the customer might have unrealistic expectations for what can be done in a 5-hour budget.
If scope, resources and time are the WHAT of a project and quality is the HOW, as you adjust different elements you have to consider the consequences. The Q*S=R*T formula gives you a language to discuss with the people on your team about how the decisions they make impact a project as a whole. When you think about your industry and the work you do, can you think of an example of how you might apply the Q*S=R*T formula to your work?