The Value Matrix: A Framework for Prioritizing Development
Software developers are content writing great applications, but consultants understand the importance of delivering big business impact.
What is the difference between a software consultant and a software developer?
Software developers focus on delivering applications that meet customer specifications.
Software consultants focus on delivering solutions that generate business value.
If you want to move from the world of software developer to software consultant, the Value Matrix is a great framework to help you with the mindset shift required to move from one role to the other.
The Value Matrix
As shown above, the value matrix has two axes:
- Development Effort
- Business Impact
This is the amount of effort required by you–the developer–to provide a software solution. It could be a bug fix, a single feature, or an entire application.
This is a COST to you, the developer.
If you charge by the hour, you are passing this cost along to your client more or less directly. However, it is important to remember that it ultimately begins as YOUR cost as the developer.
YOU, the software consultant, are the only one who can accurately estimate development effort.
This is the value your software solution provides to the end user (i.e., your client).
The more value you can provide to your client, the more they will be willing to pay for your services.
Your CLIENT, the business, dictates this value.
The Four Quadrants
Obviously, the goal is to maximize business value while minimizing development effort.
While our goal as software consultants should be to continuously move up and to the left on the matrix, we can still deliver positive return on investment (ROI) in three of the four quadrants.
The Holy Grail of software projects are those where you can provide big business impact for your client with minimal development effort.
These types of projects do exist, but you will never find them by thinking like a software developer. You uncover these opportunities only by truly understanding your client's business domain.
You can do this one of two ways:
- Specializing in a vertical and working with enough different clients to gain a deep understanding of what solutions provide the biggest business impact; OR
- Having what Jonathan Stark refers to as the Why Conversation, where you drill down into the underlying reason that your client came to you in the first place
If you can get good enough at the second option, then you can start spending some serious time in the Max ROI quadrant.
And if you can live in the Max ROI quadrant then you can ditch hourly billing entirely and dramatically increase your profit with value based pricing.
This is harder than it sounds (and it doesn't sound easy to me). I've hit one home run with this approach, but overall I've struggled to make it work on a consistent basis.
When working with a new client, there's an initial period of trust-building.
During this time, it's important to demonstrate that you can deliver a working solution to your client.
The true value of easy wins is that they help you establish trust.
It would be great if we could always deliver big value with minimal effort.
Unfortunately, that is not reality. Sometimes big problems call for big solutions. As long as those projects deliver big value, you will still be delivering positive ROI for your client. The challenge with big projects is that they are inherently risky.
This is why it's so important to develop a rapport with a client through easy wins before diving into a big project.
As a struggling software consultant–especially one who bills by the hour–it's tempting to see this quadrant as a necessary evil.
Clients will often ask you to do things without understanding the full extent of the effort required. You may even find yourself wondering why they want to sink so many resources into such a small effort. When you have such a project, it's usually for one of two reasons:
- The client underestimates the development effort
- You, the consultant, underestimate the business impact
Before beginning work on such a project, it's important to figure out which one it is. If it's number 1, then you are operating in the Negative ROI quadrant and it is your ethical responsibility to talk the client out of the project because they will be paying you more than the project is worth.
However, if it's the second option, and you simply fail to understand the full scale of the business impact, then it could be that the project actually belongs in the upper right quadrant–a big project with positive ROI.
Remember, while you are the expert on development effort, the client is the expert on business impact.
Non-technical clients are notoriously bad at estimating development effort.
Features that they think will be easy to develop may be loaded with hidden complexity. Features that they wouldn't even consider due to their assumed complexity may turn out to be easy to implement.
The best way to deliver positive ROI is to be up front with the client when estimating development effort and to fully understand the underlying reasons why your client needs your help.