If you are a project manager that does software projects, you deal with the “top side” of product investment all the time. Whether your teams are running agile like scrum or kanban, or whether they are running a phase-gated cycle (waterfall), you are focused on the decisions about organizing the investment into packages for release or deployment. You are running the factory which takes requirements in one end and (hopefully) spits working features out the other. You are working with the analysts or product people to ensure that there are enough requirements, stories, or ideas “ready to start” to keep the team occupied.
But what about the other side of product investment? We often talk about return on investment or ROI, but most organizations only use an ROI project to justify the investment. Some will go as far as to attempt to measure “hard” ROI numbers, but frankly even that is missing half the boat because it is hard to measure the impact of software capability on your organizations top line or bottom line. Without a body count, the best we can do is to infer the correlation of software capabilities to a movement in profitability and assume that the relationship is causal. When it comes to softer benefits like risk reduction, customer satisfaction, or employee retention, there is no reasonable way to measure “hard” ROI dollars.
When contemplating the other side, it is not ROI, but “business value” that I want to understand. Business value always relates to increased revenue, or reduced cost. Its pretty much that simple. Whether I am delivering software for sale to clients, to internal employees as users, or as a means of generating tertiary revenue (Internet model), business value is directly related to the adoption of the software capabilities that were delivered.
Value accrues from a project in direct proportion to the adoption of the capabilities delivered through that project. The more customers that buy the product, the more value it generates. The more users that use the product, the more value it generates. The more “things” that are done using the product, the more value it generates.
Adoption is the leading measure of value generation. If the software is useful, it generates value. When. You. Use. It. If the software is useful, people will want to use it. But it has to be more useful than the alternative. To be honest, if it is less useful than pen and paper, people will prefer to use pen and paper. They will resist adopting the software capabilities, because pen and paper is more useful. To. Them. If nobody uses it, it is hard to make a case for value add.
Gotta deal with the buts…
When software is useful, there is often still resistance to adoption. The resistance is often expressed in a statement that begins “I see that the software is useful, but…” The “but” typically is an expression of a lack of “quality”. That quality may be something that we think of as traditional software quality (buggy, crashy or slow) , or it may be something different – “user experience”, data quality, not sufficiently complete to allow users to adopt. If we start to think of quality as anything other than usefulness that inhibits adoption, we get a much clearer picture of what to do.
The thing is, Adoption is pretty easy to quantify. Pretty easy to tell how many people are using a system, how many “things” are done using that system. So if you can also quantify the unit utility of the system capability – you can calculate value generated. For example, if I say that using the old way it takes 18 minutes “wall clock” time to finish a task, and on the new system capability it takes 3 minutes, than every time that task is done on the new system we have a value generated of 15 minutes of time. If I do that task 6400 times per year, I save the equivalent of one FTE (full time equivalent).
What if we force people to use the system? What do you think happens if the time to finish the task is 22 minutes using the new system capability? Will users want to adopt it? If they do will value accrue? No – this capability bleeds business value – it costs you money to use relative to the old way. The greater adoption, the more you lose. This is especially true when you have a captive user base, who “must” use the new capabilities.
We should all apply this concept in developing a product road map. You can add value by making a small number of tasks take much less effort, or a large number of tasks take marginally less effort. You can organize the sequence of delivery by the tasks you are improving, and tackle one task at a time, or you can look at the overall “architecture”, and make some general improvements that have a value positive impact on many tasks. But if users don’t adopt the new capabilities, the value does not accrue.
What I want you to see, is this:
It doesn’t matter…
how much you spent or saved on the project by optimizing against the triple constraint.
It doesn’t matter how “good” the software is, how “fancy”, how “cool” – unless good, fancy and cool increase adoption.
Only two things really matter:
1) UTILITY – Does it do something useful?
2) QUALITY – Do people actually use it?
Why is this important? Because as we make decisions about HOW (the project) we deliver the capabilities, these are the parts of the the delivery that value accrues from. If we dilute the WHAT (capabilities) through our implementation, so that they are not able to do something that a user would find useful, then why bother. Likewise, if it does something useful, but it is too complicated for people to learn, too slow, too fiddly, too tweaky, too crashy, too inconsistent, whatever the adjective – users will not adopt it, so again, why bother.